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(54) Creating web content in a client and server system 



(57) In a data communication system (SYS), aclient 
unit (CU) and a server (SERV) perform a data commu- 
nication, in particular to provide the client unit (CU) with 
a instruction data set (IDS) in response to a content data 
request message (CDRQ) made by client unit (CU). An 
instruction format configuration file (IFCFG) contains a 
tree data structure (TRE) consisting of a plurality of in- 
struction format nodes (NO; ISI1, N2; H1, H1.1, H1.2, 
H1.3), each instruction format node (NO) indicating a 
particular combination of instruction elements (IE) con- 
stituting a particular Instruction format (IF) and having 
associated with It a node selection criterion (N1SEL). A 
content data request property provider unit (CDPP) ex- 



tracts and determines properties from the content data 
request (CDPP) issued by the client unit (CU). An in- 
struction format selection unit (IFSEL) searches the tree 
data structure (TRE) with the determined properties in 
order to find an Instruction format node, whose associ- 
ated node selection condition matches the properties. 
In particular, each node (NO) can comprise a screen 
template (ITEPMP) defining a particular screen layout 
including placeholders as well as an indication of some 
instruction element generation unit (OP), which will fill 
the placeholders with respective content data retrieved 
from a data base (DB), By unit of the selection procedure 
the instruction data set returned to the client unit (CU) 
can be provided in a flexible manner 
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Description 

FIELD OF THE INVENTION 

[0001] The invention relates to a server unit of a data 
communication system in which one or more client units 
are provided by the server unit with an instruction data 
set in a particular instruction format in response to a con- 
tent data request issued by the client unit. In particular, 
the invention desires to provide a mechanism by which 
the instruction format of the instruction data set (for ex- 
ample an HTML page) can be adapted, modified or var- 
ied depending on properties of the client unit as deter- 
mined from the content data request message. 

BACKGROUND OF THE INVENTION 



[0002] Computers have been conveniently used for a 
wide range of applications, e.g. ranging from simple ed- 
iting of text documents to complex distributed process- 
ing applications involving a large number of possibly dis- 
tributed data processing units and involving the transfer 
of data between the data processing units. 
[0003] With the growing number of data processing 
units having access to computer networks such as to 
local area networks or world-wide networks, e.g. com- 
pany-wide intranets or the Internet, a growing number 
of applications is offered which involve a plurality of data 
processing units. Such applications may be, for exam- 
ple, found in the field of home banking, office applica- 
tions, remote e-mail applications, supercomputing ap- 
plications or similar. In such data communication sys- 
tems, high speed links, via permanent connections, cir- 
cuit-switched connections or packet-switched connec- 
tions, are used as a communication link to exchange 
digital data at high speed (high-bit rates) such that even 
graphics data or data from moving images can be ex- 
changed among the data processing units. 
[0004] it is a typical feature in such data communica- 
tions systems that it is not required that all participating 
data processing units have the same powerful process- 
ing capabilities. That is, a main computer having pow- 
erful computing facilities can serve a number of smaller 
sub-computers through one or more of the above de- 
scribed communication links. Since typically the smaller 
sub-computers are only assigned the task of making ac- 
cess to a main computer and to request the processing 
facilities or data from the main computer whilst the main 
computer serves the data on the small sub-computers, 
the main computer is often referred to as a server (or 
server unit) and the small sub-computers are referred 
to as clients (client units). In such a scenario a client 
may typically request the execution of an application 
program at the server and may receive a data process- 
ing result or content data from the server via the network 
or the communication link connecting the client unit and 
the server unit. 

[0005] Furthermore, systems are known where a plu- 



rality of clients can connect to a portal for the execution 
of an application. A portal may be a large site in a net- 
work including a plurality of servers which provide a va- 
riety of services including, for example, office applica- 
s tions, searching functions, news functions, e-mail appli- 
cations, discussion groups, on-line shopping and links 
to other sites on the network. A portal may thus be a 
genera] purpose site offering the capability to perform 
applications on behalf of a client or assisting a client in 
w executing the application. 

[0006] Generally, in a client and server or portal sce- 
nario the server may be a large computing device which 
has also the resources to store and execute application 
programs which are used in providing services to a cli- 
13 ent. Since the applications and sufficient computing 
power are generally available at the server side, the cli- 
ent may be a data processing unit with less powerful 
computing resources, functioning as an interface to re- 
ceive user commands required for execution of a de- 
20 sired application program when providing the request, 
I.e. to transmit commands from the client to the server, 
and further to receive and, for example, to display com- 
putation results from the server. 

25 CONVENTIONAL SERVER AND CLIENT 
CONFIGURATION 

[0007] A typical data communication system SYS of 
the prior art is shown in Fig. 1 . Here, a server unit SERV 

30 and client units CL1 , CL2, CL3, CL4, CLN commu- 
nicate through communication links CL, possibly 
through an Intranet and/or the Internet. Fig. 2 shows a 
typical block diagram of a server unit SERV and a client 
CU in accordance with the prior art. The server unit 

35 SERV and the client CU communicate through a com- 
munication link CL connected to a respective interface 
l/F. 

[0008] Typically, the server unit SERV comprises a re- 
quest message receiving unit RMRO, a server process- 

40 ing unit SPM including an Application Programming In- 
terface API, some data processing units DPU (if the 
server is a JAVA® based server (JAVA® is a registered 
trademark of Sun Microsystems) these data processing 
units DPU are for example servlets or JAVAserver pag- 

45 es), a content data provision unit CD-PM, a local data 
base DB, where the content data, e.g. HTML pages, are 
stored, and an instruction format set-up unit IFSU which 
essentially sets the MIME-type indicating a particular in- 
struction format for the pages to be returned to the client 

so unit. 

[0009] Typically, the client unit CU comprises a con- 
tent data request unit RM, a oil ent processor CU-PM and 
a number of programs PRGs, for example, a content da- 
ta requesting unit in the form of a browser. Furthermore, 
55 the client unit CU can comprise a display DSP and a 
page setting unit PSET. 

[0010] Fig. 3 shows an example of operations typical- 
ly carried out by the client side and the server side for 
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the typical scenario in Fig. 1 . 




ation ST10. 



CONVENTIONAL TRANSFER OF CONTENT DATA 
TO THE CLIENT 
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[0011] For example, in case a user at a client side 
wishes to access a document from the server SERV, e. 
g. a web-page available at the server or another loca- 
tion, the user selects in operation ST1 one of the pro- 
grams PGs, e.g. a particular browser, which is run on 
the client processor PU-PM. When the user clicks on a 
particular place on the screen, a content data request 
unit RM sends a content data request CD RQ to the serv- 
er SERV In operation ST2. in the Internet protocol, such 
a request message CDRQ can typically be an HTPP 
message requesting the transfer of HTML-pages from 
a database D8 located within the server SERV (or lo- 
cated elsewhere outside the server). The HTTP-request 
message includes the URL from which the HTML-pages 
should be retrieved and some additional header infor- 
mation. 

[0012] After setting up the communication link CL be- 
tween the client unit CU and the server unit SERV, the 
request message reception unit RMRU on the server 
side receives the content data request message CDRQ 
in the operation ST3. Alternatively, the client unit CU can 
also request the execution of some processing pro- 
grams DPU, so-called servlets, by the server unit SERV. 
[0013] In the operation ST4 the server processing unit 
SPM together with the content data provision unit 
> CD-PM statically or dynamically retrieves the requested 
: content data, e.g. the HTML-pages. In astatic retrieval, 
the server processing unit SPM merely accesses a local 
database DB and retrieves the HTML-pages. In a dy- 
namic retrieval the server processing unit SPM can run 
additional programs, for example, the sen/lets, in order 
to retrieve data also from a remote site in a dynamic 
manner, in this connection, the Application Program- 
ming Interface API is used for coordinating which of the 
servlets are used. After the operation ST4 an operation 
ST5 follows in which the page format for the client Is 
determined. This will be explained below. 
[001 4] In the operation ST6 the content data providing 
unit CD-PM of the server unit SERV provides through 
the communication link CL the retrieved content data, i. 
e. an instruction data set to the client side. In the oper- 
ation ST7, the content data or the instruction data set is 
received on the client side and in the operation ST8 the 
user at the client side has the option to display or print 
out the transferred content data on a display DSP, on a 
disc or a printer. If the requested content data are web- 
pages (HTML-pages), typically complete data sets re- 
lating to one page are requested and retransferred to 
th e client side. Therefore, If in the operation ST9 the user 
requires further pages, i.e. data sets, from the server, 
the process continues with the operation ST2. If no fur- 
ther pages are required, the fink is closed after some 
time, for example, by stopping the browser in the oper- 



STRUCTURE OF THE INSTRUCTION DATA SET 

5 [0015] Fig. 4 shows an example of the HTTP request 
and HTTP reply scenario between the client unit CU and 
the server unit SERV for the case where the data set to 
be transferred back to the client unit CU contains con- 
tent data which on the client side CU Is to be used for a 

10 screen display. As shown In Fig. 4, the HTML-page com- 
prises a screen layout format IF including a plurality of 
screen elements IE1 , IE2. Here, the screen element IE1 
is a log-in element and the screen element IE2 is a com- 
pany logo. Furthermore, the screen layout IF can, for 

« example, comprise a particular background colour. That 
is, in the case of Fig. 4 the screen format IF is constituted 
by a data set which comprises graphics data. In order 
for the client unit CU to recognize that the transferred 
data set comprises graphic element data sets, an in- 

20 struction format setup unit IFSM shown in Fig. 4 and in 
Fig. 2 on the server side determines a so-called MIME- 
type which indicates the type of data contained In the 
HTML-page to be transferred to the client CU. There- 
fore, the operation ST5 In Fig. 3 determines the MIME- 

25 type and transfers an indication of the MIME-type to the 
client unit CU together with the data set In step ST6. On 
the basts of the MIME-type, the client unit CU can rec- 
ognize that the transferred data set comprises graphics 
element data sets which can be displayed on the display 

30 DSP. Thus, in this case the transferred HTML-page is 
intended merely for being displayed on the display 
screen DSP. 

[0016] However, the transferred data sets from the 
server unit SERV may not only constitute a graphics da- 

35 ta set to be displayed on a display screen DSP but can 
also be a general instruction data set which the user can 
use for other purposes In the operation ST8. For exam- 
ple, the user at the client unit CU may request a transfer 
of a command data set for controlling a device on a client 

40 side CU, for example, a robot. That is, the client unit CU 
may not necessarily use the transferred data set for a 
display but for a control of a device. 
[001 7] Whilst in this case there is no necessity to dis- 
play the commands on the display screen DSP, the 

45 HTML-page transferred from the server unit SERV will 
nonetheless have a particular instruction format IF sim- 
ilarly as the one shown for the screen layout in Fig. 4. 
That is, when the command data set Is requested, it will 
also contain specific instruction elements correspond- 

50 ing to instruction element data sets In the instruction da- 
ta set to be transferred to the client unit CU. 
[0018] Hence, independently of what use is made at 
the client unit CU, every transferred instruction data set 
will have a particular instruction format IF consisting of 

55 a plurality of instruction elements and the MIME-type will 
indicate to the client unit CU the type of data which is 
transferred. Thus, generally an instruction data set is 
transferred back to the client unit CU and this instruction 
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data set will comprise a plurality of instruction element 
data sets corresponding to the particular instruction el- 
ements forming the data set. Therefore, display frames 
for local visualization at the client side or command 
frames for other use at the client side can be transmitted 
from the server to the client unit as HTML-pages. 

STRUCTURE OF DATA REQUESTS 

[0019] Furthermore, white in the above description it 
has been assumed that the request unit RM merely 
sends a content data request CDRQ to the server unit 
SERV, of course, more complex operation commands 
can be transmitted to the server side in a similar manner. 
For example, in case the client wishes to scroll through 
a document, a corresponding input command is given 
via the browser and is transmitted via the communica- 
tion link to the server. In turn, the server prepares a cor- 
responding display content for transfer to the ciient in 
order to enable the client to locally visualize changed 
display content. Similarly, in case the user wishes to edit 
the document, respective commands could be transmit- 
ted from the dient to the server and according ly be proc- 
essed at the server. Changed display contents (content 
data) can then again be transmitted to the client for the 
local visualization on the display unit. 
[0020] However, it is also possible, that not only the 
server has the necessary resources to provide a desired 
service, but a client may already have the required re- 
sources for providing the service such as rendering op- 
erations or editing a data file. Corresponding application 
programs may thus be available at both the client side, 
e.g. an applet, and the server side, e.g. a servlet, for 
performing a desired operation, i.e. providing a desired 
service. Such programs are also available as one of the 
programs PRGs shown on the client side in Fig. 2. 
[0021 ] Since on the client side CU different browsers 
or different processing programs PRGs can be executed 
or different devices can be used on the client side CU, 
the server side SERV must also have knowledge about 
what type of program is run in order to determine in 
which manner the retrieved HTML-pages should be pro- 
vided back to the client unit CU. 
[0022] Typically, a content data request CDRQ issued 
by the request unit RM also contains request parame- 
ters, request header parameters, device properties and 
resource properties. 

[0023] Device properties are used in conjunction with 
the client device. These properties refer to such things 
as the different display sizes of the client devices. 
[0024] Resource properties cover all the properties 
that are assigned to a requested document or more gen- 
erally to a resource. This, for example, includes the var- 
ious document types (Star Office documents, Star Office 
write, Star Office calculator or other document formats 
such as PDF as well as customized content types used 
for folders, for example). 

[0025] Since the server unit SERV can be accessed 



by different browsers, for example, Netscape browser 
4.X and the Internet Explorer, special add-lns are re- 
quired in each browser such that a document can be 
edited. To enable the dynamic download of the correct 

3 add-in, the browser type can be identified via request 
header parameters of the request message CDRQ. 
[0026] Finally, for the above-described custom com- 
mands issued by the client unit, so-called request pa- 
rameters are available in the request message CDRQ 

io such that the commands can be recognized on the serv- 
er side. 

DISADVANTAGES 

*5 [0027] Despite the fact that according to the prior art 
it is already possible to transfer in the content data re- 
quest CDRQ (a HTTP-request) information of the re- 
quest parameters, request header parameters, device 
properties and resource properties, the server unit 

so SERV simply retrieves the HTML-page (the content da- 
ta) and determines the MIME-type and then provides 
back to the client unit CU a corresponding data set in- 
cluding a fixed instruction format IF determined by the 
MIME-type. That is, despite the fact that some informa- 

25 tion about the client unit properties and/or resource 
properties are transferred to the server unit SERV in the 
request message CDRQ, the format of the data set 
transferred back to the client unit CU Is fixed, i.e. Inde- 
pendent of the properties. Thus, independent of the ca- 

30 pabilities of the client unit CU the same format will al- 
ways be used (only the MIME-type is determined to tell 
the client unit what type of data is retransferred). Con- 
sequently, the page set up unit 1FSET uses a rather fixed 
frame or instruction data set format when retransferring 

35 the requested data. Thus, the main disadvantage re- 
sults that, independently of the capabilities of the client 
device, the executed browsing program, the set options 
on the browsing program and the type and size of the 
requested content data, the instruction format (screen 

40 format or command format) remains the same. 

[0028] That is, it would generally be desirable to pro- 
vide a flexible and extendable framework for creating 
content depending on the client unit or resource prop- 
erties, i.e. the server unit SERV should be capable of 

45 changing the instruction format depending on the client 
capabilities and the type of requested content data. 

SUMMARY OF THE INVENTION 

50 [0029] It is therefore desirable to provide an improved 
server unit and a method for exchanging data between 
the server unit and the client unit in a data communica- 
tion system which allow the server unit to make the in- 
struction format of the instruction data set flexibly de- 

« pendent on the capabilities of the client unit and the 
properties of the requested content data. 
[0030] The invention as recited in the independent 
claims allows the server unit to make the generation and 
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retrieval of the content data and its format dependent 
on the properties of the client unit and the properties of 
the resources. For this purpose the server unit selects 
from a number of Instruction format templates a partic- 
ular instruction format template dependent on a client 
or resource properties. 

[0031] The template describes at what positions in the 
data set particular instruction elements can be placed. 
The data which is inserted in the places indicated in the 
instruction format template will then be filled by a par* 
ticular instruction element generating unit which yet 
again has been selected, In accordance with the client 
capabilities or resource capabilities, from several avail- 
able instruction element generating units. 
[0032] The special selection of the Instruction format 
template and of the special instruction element gener- 
ating units is made by searching a tree node structure 
with the client or resource properties wherein each node 
corresponds to aparticulartemplate or a particularcom- 
bination of instruction element generating units. When 
the properties with which the search is done match a 
node selection criterion associated with each node the 
particular template or combination of Instruction ele- 
ment generating units is executed. 
[0033] Thus, a flexible and extendable framework for 
creating content is provided by providing a new way of 
registering new content creation servlets and by chang- 
ing how existing content is created. The tree structure 
for the search thus makes it easy to select and execute 
the appropriate instruction element generating units for 
flexibly adapting the instruction format. 
[0034] Thus, a server unft of a data processing system 
in which one or more client units are provided by the 
server unit with an Instruction data set In a particular in- 
struction format In response to a content data request 
comprises a content data request property provider unit 
for providing one or more content data request proper- 
ties of the content data request made by a client unit; 
an Instruction format set up unit for preparing an instruc- 
tion data set having the instruction format and consisting 
of a plurality of Instruction element data sets each rep- 
resenting a particular instruction element of the instruc- 
tion format and generated by one or more instruction 
element generating units of said instruction format set 
up unit; an Instruction format configuration file contain- 
ing a tree data structure consisting of a plurality of in- 
struction format nodes, each instruction format node In- 
dicating a particular combination of instruction elements 
constituting a particular instruction format and having 
associated with it a node selection criterion; an instruc- 
tion format selection unit for searching said tree data 
structure with the determined content data request prop- 
erties and for selecting an instruction format node 
whose associated node selection condition matches 
said determined content data request properties; and 
said instruction format set up unft preparing the instruc- 
tion data set to be sent to the client unit by executing 
the instruction element generating units of the selected 



instruction format node. 

[0035] The content data request property provider 
unit may advantageously analyse said content data re- 
quest to provide one or more client unft related proper- 
5 ties and content data related properties. 

[0036] The content data request property provider 
unit can comprise a number of units for determining the 
properties in different categories. Thus, advantageously 
the content data request property provider unit includes 
10 a device property provider unit for providing for each cli- 
ent unit as said client unit related properties device prop- 
erties about the client unft device; a resource property 
provider for providing as said content data related prop- 
erties resource properties about data content resources 
is providing the content data; a content data requesting 
unft property provider for providing as said client unit re- 
lated properties about the content data requesting unit 
used at the client units; and a command property pro- 
vider unit for providing as said client unft related prop- 
20 erties, properties about commands Issued at the client 
units (CU). 

[0037] Furthermore, the content data request proper- 
ty provider unft can include a first property memory for 
client unit related properties and a second memory for 

2s content data related properties. 

[0038] The content data request property provider 
unit can analyse a first content data request to obtain 
said client unit related properties and said content data 
related properties, wherein at the arrival of any subse- 

30 quent content data request in the same session said 
content data request property provider only accesses 
said first memory or said second memory to provide said 
client unit related properties and/or said content data re- 
lated properties. Since properties from previous content 

35 data requests are stored in the respective memories, it 
is not necessary to send all the parameters with subse- 
quent content data requests and instead of this the de- 
tails of previous requests can be accessed. 
[0039] Furthermore, the node selection condition can 

to comprise one or more node selection requirements in- 
cluding at least one property name parameter and an 
expected property; wherein said instruction format se- 
lection unit is adapted for starting the search at the root 
Instruction format node; wherein said instruction format 

45 selection unit Is adapted for requesting from the property 
provider unit for the current content data request a prop- 
erty relating to the property name parameter of a node 
selection condition of a next instruction format node; 
wherein said Instruction format selection unit is adapted 

so for branching to said next instruction format node, if the 
provided property matches with the expected property. 
When searching from the route node through the other 
nodes of the tree structure it is also possible that an in- 
struction template "learned* 1 further above in the search 

55 process can be "inherited" by a node further down which 
itself has no specification of such an Instruction tem- 
plate. The search through the tree structure Is terminat- 
ed when a child node with no further depending nodes 
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is found. The Instruction format can include an instruc- 
tion template and a plurality of instruction element posi- 
tions Into which the instruction element generating units 
insert instruction element data sets when they have 
been executed. 

[0040] The instruction data set can be a set of i nstruc- 
tion data for displaying a screen with a particular screen 
layout format on the client unit, wherein the instruction 
template is a screen layout template and said instruction 
element positions are placeholders into which the in- 
struction element generating units insert screen ele- 
ment data sets when they have been executed. Thus, a 
screen Is a template with a set of arguments and a tem- 
plate describes at what positions the arguments are in- 
serted in the template in the process of creating the re- 
sponse. 

[0041] The instruction data set can also be a set of 
instruction data for controlling a device with a particular 
control command layout format on the client unit, where- 
in the instruction template is a command layout template 
and said instruction element positions are command 
holders into which the instruction element generating 
units insert command data sets when they have been 
executed. Thus, a command instruction data set can be 
formed in a flexible manner, e.g. an instruction format 
with basic instructions and sub-instructions can be 
formed in a flexible manner. 
[0042] Thus, a method in a data processing system 
for providing one or more client units by a server unit 
with an instruction data set in a particular instruction for- 
mat in response to a content data request, comprises: 
providing one or more content data request properties 
of a content data request made by a client unit; prepar- 
ing an instruction data set having the Instruction format 
and consisting of a plurality of instruction element data 
sets each representing a particular Instruction element 
of the Instruction format; searching a tree data structure 
stored in an Instruction format configurationfile and con- 
sisting of a plurality of instruction format nodes, each 
instruction format node indicating a particular combina- 
tion of instruction elements constituting a particular in- 
struction format and having associated with ft a node 
selection criterion, with the determined content data re- 
quest properties and for selecting an instruction format 
node whose associated node selection condition match- 
es said determined content data request properties; and 
preparing the Instruction data set to be sent to the client 
unit by executing instruction element generating units of 
the selected instruction format node. 
[0043] When the node selection condition comprises 
one or more node selection requirements Including at 
least one property name parameter and an expected 
property, the method can comprise the steps of starting 
the search at a root instruction format node; requesting 
from a property provider unit for the current content data 
request a property relating to the property name param- 
eter of a node selection condition of a next instruction 
format node; and branching to said next instruction for- 



mat node if the provided property match with the expect- 
ed property. 

[0044] A computer program product stored on a com- 
puter-readable storage medium comprises code units 

5 adapted to carry out the aforementioned operation. Fur- 
thermore, a program has instruction adapted to carry out 
at the server side the aforementioned operations. Fur- 
thermore, a data carrier for a server side having com- 
puter-readable storage code embodied therein compris- 

10 es units for providing one or more content data request 
properties of the content data request made by a client 
unit; units for preparing an instruction data set having 
the instruction format and consisting of a plurality of in- 
struction element data sets each representing a panic- 
's ular instruction element of the instruction format and 
generated by one or more instruction element generat- 
ing units of said unit; units containing a tree data struc- 
ture consisting of a plurality of instruction format nodes 
each instruction format node indicating a particular com- 

20 bination of instruction elements constituting a particular 
instruction format and having associated with it a node 
selection criterion; units for searching said tree data 
structure with the determined content data request prop- 
erties and for selecting an instruction format node 

25 whose associated node selection condition matches 
said determined content data request properties; and 
said units being adapted for preparing the instruction da- 
ta set to be sent to the client unit executing the instruc- 
tion element generating units of the selected instruction 

30 format node. 

[0045] Furthermore, the client unit and the server unit 
are JAVA based units, wherein the Instruction format 
configuration file containing the tree data structure is a 
JAVA XML file. In such a case, the node selection crite- 

35 don can be f ormed by one or more of a requirement type, 
a requirement name, a requirement value and an oper- 
ation type. Furthermore, the instruction element gener- 
ating units can comprise a component name and an ar- 
gument name through which execution programs of 

40 JAVA server pages or a servlet are executed. Further- 
more, in the argument name substitution names can be 
formulated. 

[0046] Further advantageous features and improve- 
ments of the invention can be taken from further de- 
45 pendentclafrns. Furthermore, the server unit and the da- 
ta communication system and the method may com- 
prise features, which have been separately described 
and claimed in the specification and the claims, respec- 
tively. 

50 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0047] In the drawings, the same or similar reference 
numerals denote the same or similar steps or parts 
55 throughout. 

Fig, 1 shows a data communication system 

in which a server and a plurality of cli- 
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ents perform a data communication in 
accordance with the prior art; 

Fig. 2 shows a block diagram of a client unit 

and a server unit in accordance with 5 Fig, 8c 
the prior art; 

Hg. 3 shows a client/server communication 

when the client requests the transfer 
of content data from the server, in ac- 10 
cordance with the prior art; 



25 
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35 



Fig. 4 shows an example of transferring a 

HTML-page with a particular screen 
layout format to the client unit, In ac- 
cordance with the prior art; 

Fig. 5a shows a server unit and a client unit 

for explaining some basic aspects of 
a general embodiment; 

Fig, 5b shows a flowchart of some basic pro- 

cedures of the general embodiment; 

Fig. 5c shows the setting of a template and 

places for the instruction format, in ac- 
cordance with the general embodi- 
ment; 

Fig. 5d shows a block diagram of a server unit 

and a client unit in accordance with a 
more detailed embodiment of the In- 
vention; 

Fig. 6 shows the content of the instruction 

format configuration file including a 
tree structure and the content of the 
instruction format set up unit; 

Fig. 7a shows an part of the method in ac- 

cordance with an embodiment of the 
invention, in particular the operations 
for providing the content data request 
properties on the server side; 

45 

Fig. 7b shows a part of the method in accord- 

ance with an embodiment of the in- 
vention, in particular showing the op- 
erations for searching and preparing 
the instruction format; so 

Fig. 8a shows a diagram similar to Fig. 4, 

when transferring to the client unit an 
instruction data set having an instruc- 
tion format as formed by the present ss 
Invention; 

Fig, 8b shows an example of a template and 
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a placeholder for a log-in page, when 
the screen template is first set up and 
subsequently filled with data; 

shows an example similar to Fig. 8b 
where a screen template comprises a 
plurality of placeholders which are 
filled with data by a plurality of select- 
ed instruction element generation 
units (components) ; 

shows a flow chart of the operation S7 
in Fig. 7b; 

shows a typical tree structure stored 
in an instruction format configuration 
file, In accordance with one embodi- 
ment of the invention; 

shows the content of the processing 
carried out in the instruction format se- 
lection unit in particular an XML rep- 
resentation of main nodes In the tree 
structure of Fig. 10a; 

shows a tree structure for the sub- 
nodes of the tree shown In Fig. 10a; 

show the content of the instruction for- 
mat selection unit IFSEL as an XML 
file, in particular showing the definition 
of the sub-nodes of Fig. 10c; and 

show the content of the instruction for- 
mat selection unit IFSEL as an WML 
file, In particular showing the definition 
of the sub-nodes of Fig. 1 0f. 



40 



DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 



[0048] Hereinafter, embodiments of the Invention will 
be described with reference to the drawings. Whilst 
hereinafter often reference Is made to special message 
exchanges between a client unit and a server unit in an 
Internet application example where web-pages are re- 
trieved from a server unit in a JAVA-environment, it 
should be understood that the invention is not limited to 
the special JAVA data communication implementation. 
[0049] The invention can be applied to any client serv- 
er scenario, Independent of the type of client and server 
implementation used. Furthermore, hereinafter refer- 
ence is often made to the case where a special screen 
layout is adaptfvely prepared as said instruction format. 
However, the invention is not restricted to setting up a 
screen layout and any other instruction format including 
command instructions or similar can be used. 
[0050] Before coming to a more detailed description 
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of other embodiments, hereinafter we describe some 
aspects of a general embodiment with reference to Fig. 
5a, 5b. 

[0051] In Fig. 5a, a general server SERV has a con- 
tent data provider unit CD-PM, which essentially re- 
trieves content data from a data base DB, e.g. in the 
form of HTML pages. Furthermore, a unit is provided 
which Is here called the screen registry I REG. It gener- 
ally contains two memories MEM1, MEM2. The server 
SERV is to provide an instruction data set IDS in a par- 
ticular instruction format IF to the client unit CU. This is 
generally done by means of a HTTP response message, 
as was explained above. The screen registry I REG pro- 
vides some information P on the capabilities of the client 
unit CU and/or the properties of content data, e.g. from 
the content data requested by the client unit CU , at least 
to the content data provider CD-PM. 
[0052] Thus, the server unit SERV Is adapted to make 
the Instruction format IF of the instruction data set IDS 
flexibly dependent on the capabilities of the client unit 
CU and/or the properties P of the content data CD. That 
Is, as shown in the general method of Fig. 5b, first there 
is a property provision procedure SS1 in which the 
screen registry IREG provides the capabilities (proper- 
ties) of the client unit CU and/or information on proper- 
ties of some content data CD. Then, there follows an 
instruction data set provision procedure SS2, in which 
the Instruction data set IDS adapted for example in Its 
format in accordance with the determined properties, is 
provided to the client unit CU. Thus, the data set IDS is 
flexibly dependent on the properties. 
[0053] According to another embodiment, as shown 
also in Fig. 5a, the screen registry IREG can also pro- 
vide the properties P to the data base DB, which stores 
the content data CD, which is possibly requested by the 
client unit CU. Then, the server unit SERV, more pre- 
cisely the content data provider unit CD-PM, can also 
make the generation and retrieval of content data CD 
and its format flexibly dependent on the properties of the 
client unit CU and/or the properties of resource units, 
which provide said content data CD. Therefore, accord- 
ing to this embodiment, already the retrieval of the data 
and not only the adaptation of its format can be made 
flexibly dependent on the relevant properties. 
[0054] Whilst in accordance with one embodiment the 
screen registry IREG has already stored the client unit 
or content data related properties in the screen registry 
IREG, for example the client unit-related properties in a 
first memory MEM1 and the content data related prop- 
erties In a second memory MEM2, in accordance with 
another embodiment, the screen registry, more precise- 
ly a content data request property provider unit CDPM 
(see the more detailed block diagram in Fig. 5d to be 
described below) is adapted to analyse a content data 
request (i.e. the HTTP request) in order to find out the 
one or more client unit related properties and content 
data related properties. 

[0055] The properties detected from the content data 



request can be used for many other purposes in addition 
to the purpose of flexibly retrieving and/or adapting of 
the format of the instruction data set IDS. However, ad- 
vantageously, the flexible retrieval of a content data and/ 

5 or the changing of the format of the instruction data set 
IDS can be varied in accordance with the properties 
which have been determined by analysing the content 
data request. Thus, the content of the first memory and 
the second memory, i.e. the relevant properties stored 

10 therein, can determine the formatting and/or retrieving 
and processing of the content data. 
[0056] According to another embodiment, it is very 
advantageous, if the generation of the instruction data 
set IDS Is separated in two parts, namely in a first part, 

J5 in which a selection unit IFSEL (see the more general 
block diagram in Fig. 5d) selects from a number of in- 
struction format templates ITEMP a particular instruc- 
tion format template ITEMP as shown in Fig. 5c. This 
template describes at what places In the instruction data 

20 set IDS particular instruction elements IE can be placed. 
As will be understood from Fig, 5a, such a selection of 
an instruction format template ITEMP can be made de- 
pendent on the client properties P. Thus, in accordance 
with different properties, different templates can be se- 

25 lected. 

[0057] Furthermore, the template ITEMP selected by 
the selection means in accordance with the properties 
can comprise places into which respective instruction 
element generating units will insert data, as already in- 

30 dicated with the hatched portion in Fig. 5c. The selection 
unit IFSEL can also select for each of the pre-speclf led 
places IE1 , IE2 in the selected template ITEMP, the re- 
spective Instruction element generating units in accord- 
ance with the client capabilities or resource capabilities 

35 p. Therefore, the selection of the template and/or the 
selection of the generation unit responsible for inserting 
data Into the places can be made dependent on the 
properties P provided by the screen registry IREG. 
[0058] In accordance with another embodiment, the 

40 aforementioned selection procedures, which are de- 
pendent on the client properties and resource properties 
can be made by searching a tree structure in a config- 
uration file IFCFG with the client unit related and/or con- 
tent data related properties. In a tree structure, each 

45 node generates the instruction data set with a different 
instruction format IF. Thus, a tree structure (see for ex- 
ample Fig. 6) is used for flexibly generating the Instruc- 
tion data set, for example for flexibly selecting the tem- 
plate and the respective instruction elements generation 

50 units, for example also dependent on the client proper- 
ties and/or the content data properties. 
[0059] As wilt also be described below with more de- 
tails, in accordance with one embodiment, the tree 
structure can be in an XML configuration file, wherein 

55 S ach node in the tree structure generates the instruction 
data set IDS in a different instruction format IF with a 
screen template ITEMP generated by a template jsp 
(JAVA Server Pages) or a servlet with a set of argument 
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serviets and describing at what positions the arguments 
are to be inserted in the template. 
[0060] Above, it was already explained that the 
screen registry IREG provides the properties relating to 
the client unit and/or the resources providing the content 
data. However, the properties may also reiate to other 
factors of external influences and the provided proper- 
ties used for the selection are not restricted to the client 
unit properties and the resource properties detected 
from the content data request message. Any other type 
of property can therefore be used for the selection pro- 
cedure. 

[0061] Furthermore, in accordance with one embodi- 
ment, the tree structure is fixed and is independent from 
the individual sessions built up between the server 
SERV and the client unit CU . in accordance with another 
embodiment, the tree structure in the configuration file 
can, however, be set new during each session. Further- 
more, in accordance with yet another embodiment, it is 
also possible that the tree structure itself is made de- 
pendent on the properties, i.e. the client unit related 
properties and/or the content data or resource proper- 
ties. 

[0062] Therefore, in the description of the other em- 
bodiments below, it should be noted that many opera- 
tions and units can operate dependent on properties, 
even if it is not explicitly described. Thus, a full flexibility 
is obtained in providing the instruction data set to the 
client unit in an as flexible as possible manner. This flex- 
ible adaptation procedure is hereinafter described with 
further embodiments, wherein further details of the 
above described general embodiments will become ap- 
parent. 

DETAILED CONFIGURATION OF THE SERVER AND 
THE CLIENT 

[0063] A first embodiment of the Invention will be de- 
scribed with reference to Fig. 5d showing a server unit 
SERV and a client unit CU and Fig. 7a t 7b showing op- 
erations when communicating messages between the 
server unit SERV and the client unit CU. 
[0064] The server unit SERV shown in Fig. 5d in- 
cludes, as the server unit SERV the prior art in Fig. 2, a 
server processing unit SPM including an Application 
Programming Interface API, a content data provision 
unit CD-PM, a request message reception unit RMRU, 
a database DB including content data, for example, in 
the form of HTML-pages, and an interface l/F for com- 
municating with the client unit CU, Furthermore, the Ap- 
plication Processing Interface API handles one or more 
data processing units DPU, e.g. serviets. That is, as the 
prior art server unit SERV in Fig. 2, also the server unit 
SERV in Fig. 6d can receive a content data request 
CDRQ from the client unit CU, can retrieve content data, 
for example directly in a static way from the local data- 
base DB, or in a dynamic manner by executing a servlet 
to acquire the content data from a remote location, The 



content data providing unit CD-PM carries out this col- 
lection of content data and can transf e r back to the ciient 
unit CU a response message including the content data 
as a data set, for example, as an instruction data set in 

5 a particu lar instruction format I F. 

[0065] In addition, the server unit SERV in Fig. 5d 
comprises a content data request property provider unit 
CDPP, an instruction format set up unit IFSET, an in- 
struction format configuration file IFCFG and an instruc- 
ts tion format selection unit IFSEL The provider unit 
CDPP, the unit IFSET, IFSEL and the configuration file 
IDCFG are part of a general unit which is here called the 
screen/instruction registry IREG. As will be explained 
below with specific reference to the Individual functions 
carried out by these units, the overall purpose of the 
screen/instruction registry IREG is to obtain from a re- 
ceived content data request CDRQ certain properties 
about the client unit CU and the required resources and 
to perform a flexible adaptation of the Instruction format 

20 IF of the content data to be sent back to the client unit 
CU. Thus, the instruction data set will be formed by dif- 
ferent instruction elements generated by one or more 
instruction element generating units specially selected 
in accordance with the detected properties. 

25 [0066] The client unit CU shown in Fig. 5d includes, 
as the prior client unit CU In Rg. 2, a content data re- 
quest unit RM, a client processor CU-PM, a display DSP 
and a number of content data requesting units PRGs, 
such as different browser programs which are run on 

30 the ciient processor CU-PM . Each of these programs is 
adapted to output content data requests to the server 
unit SERV. Furthermore, of course, the client unit CU 
can also issue commands, either as part of the content 
data request or as a separate message. 

35 [0067] The instruction format set up unit IFSET of the 
ciient unit CU has a similar function as the page set up 
unit PSET in Fig. 2, namely to set up a special screen 
format when displaying the content data transferred 
back from the server unit SERV on the display unit DSP. 

40 [0068] Thus, Fig. 5d shows a server unit SERV of a 
data communication system SYS in which one or more 
client units CU are provided by the server unit SERV 
with an instruction data set in a particular instruction for- 
mat in response to a content data request CDRQ issued 

^5 by the client unit CU. Since the instruction data set and 
in particular its instruction format is an advantageous 
aspect of embodiments described herein, hereinafter 
the general structure of the instruction data set is ex- 
plained. 

50 

CONFIGURATION OF THE INSTRUCTION DATA SET 

[0069] Although the client unit CU may desire via the 
content data request CDRQ that some graphics display 
55 data, for example, in the form of HTML-pages, is trans- 
ferred back as content data, of course, the communica- 
tion link CL and in fact also the server SERV do not dis- 
tinguish between graphics data or other type of data, for 
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example, command data, in as far the transfer over the 
communication link CL is concerned. Since the content 
data request and response procedure is carried out in 
a one-to-one relationship, i.e. for each content data re- 
quest one instruction data set IDS is transferred back, s 
it Is useful to regard the content data transferred back 
from the server unit SERV as one complete data set (in- 
struction data set) which is self-contained and contains 
certain types of sub-data sets. 

[0070] That is, the instruction data set fOS is com- 10 
posed by a plurality of instruction element data sets 
I EDS each representing a particular Instruction element 
IE of the complete instruction format IF. The instruction 
element data sets IEDS can be distributed over the com- 
plete instruction data set IDS as shown schematically « 
on the left-hand side of the client unit CU in Fig. 5d. If 
the instruction data set relates to a graphics data set, 
the graphics screen display obtained with such an in- 
struction data set IDS is as an example shown on the 
right-hand side of the client unit CU. Thus, each partic- *Q 
ular instruction element data set IEDS1 , IEDS2, IEDS3 
would correspond to a specific screen element SE1, 
SE2, SE3 displayed at specific positions on the screen 
SCRN. Thus, a specific screen format S F would be built 
up. & 
[0071] Of course, it should be understood that there 
need not necessarily be a one-to-one positional relation- 
ship between the instruction element data sets IEDS 
and the positions of the screen elements SE. The illus- 
tration in Fig. 5d should only make clear that each indi- &> 
vidual instruction element data set IEDS will form a par- 
ticular screen element SE. However, of course, the In- 
struction data set IDS will also comprise an instruction 
format IF, that is the instruction format IF indicates via 
the instruction element data sets IEDS the format of the 35 
screen SCRN which will eventually be displayed on the 
display unit DSP. 

[0072] On the server side SERV, each of the instruc- 
tion element data sets IEDS will have been generated 
by a specially selected instruction element generating *o 
unit C01 , C02, C03 of the instruction format set up unit 
IFSET, as Indicated with dashed lines in the instruction 
data set IDS in Fig. 5d. 

[0073] Having understood the relationship between 
the Instruction format IF and the example of the screen *5 
format SF, a first advantage is that the instruction format 
IF and the screen format SF respectively, i.e. the posi- 
tional placement of screen elements SE on the screen 
SCRN, can be selected in a flexible manner in accord- 
ance with the properties of a content data request. A so 
second advantage of the Invention is, once the instruc- 
tion or screen format has been set, to allow a flexible 
filling of the instruction elements or screen elements 
with content data, also dependent on properties extract- 
ed from a content data request ss 
[0074] Incidentally, the above explanation equally 
well holds for the case where content data in the form 
of command data is transferred, instead of graphics 



screen data. As explained above, also in this case the 
data set transferred from the server unit SERV will have 
to have a certain "instruction format" , e.g. how the indi- 
vidual command element data sets will be sequentially 
arranged into main commands and subcommands, for 
example, for controlling a device on the client unit CU, 
e.g. a robot. 

[0075] Hereinafter, with reference to Fig. 5d, Fig. 6, 
Fig. 7 and Fig. 8, the procedure to adapt the instruction 
format or screen format (screen layout) dependent on 
properties of the content data request by using a tree 
structure (Fig. 6) in will be explained for several embod- 
iments. 

PROVISION OF CONTENT DATA REQUEST 
PROPERTIES 

[0076] Hereinafter, the procedure of providing a flex- 
ible instruction or screen format is also referred to as 
"screen registry operation" or "profiling service". 
[0077] Since the screen registry operation is made 
dependent on properties of the client unit or properties 
of the resources providing the content data, the actual 
adaptation procedure is preceded by a property provi- 
sion procedure as shown in Fig. 7a. In the operation S1 , 
a client side content data request unit RM is run by the 
user, e.g. a browser program, a communication link CL 
to the server unit SERV is set up and the content data 
request CDRQ Is sent from the client unit CU to the serv- 
er unit SERV in the operation S2. In the operation S3 
the request reception unit RMRU of the server unit 
SERV receives this content data request message 
CDRQ. 

[0078] As shown In Fig. 8a, in accordance with one 
embodiment the content data request CDRQ is a HTTP- 
request issued by a web browser (content data request 
unit) and in accordance with one embodiment the re- 
quest message reception unit RMRU is a front compo- 
nent or front end including a MainServlet. This Main- 
Servlet receives all requests made by the different cli- 
ents. 

[0079] In the operation S4 the content data request 
property provider unit CDPP (forming together with the 
Instruction format set up unit IFSET the profiling service) 
analyses the content data request CDRQ with respect 
to its properties. 

[0080] in the operation SS the content data request 
property provider unit CDPP, in accordance with one 
embodiment, stores the extracted properties in one or 
more memories MEM1, MEM2 of the provider unit 
CDPP When requested by the profiling service, for ex- 
ample, by the instruction format selection unit IFSEL, 
the property provider unit CDPP can read out the stored 
properties from the memory in the operation S6. 
[0081 ] To obtain a minimum amount of property infor- 
mation, at least the first content data request message 
CDRQ must be analysed with respect to the properties 
by the provider unit CDPP in the operation S4. However, 
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in the request-response scenario (one content data re- 
quest will exactly be answered by one data set (HTML- 
page), of course, it is possible that the same client unit 
will issue further content data requests CDRQ. In this 
case, it is not necessary that the provider unit COPP al- 
ways extracts the same property Information from all 
subsequent content data request messages CDRQ and 
it can be sufficient, in the same session, that the content 
data request property provider CDPP only accesses the 
memory in the operation S6 to provide for the client unit 
indicated in the content data request CDRQ the related 
properties. That is, with subsequent content data re- 
quests CDRQ, the operations S4, S5 may be skipped 
(see the bypass operation S4'). Furthermore, in accord- 
ance with another embodiment, It is also possible that 
the properties are kept or updated from session to ses- 
sion. That is, If in one session some properties have 
been determined (through one or more analyses of one 
or more content data requests in the same session), 
these properties can be "carried forward" to the next 
session, e.g. if there are permanently stored in the mem- 
ories MEM1 and MEM2. 

[0082] Furthermore, it should be noted that properties 
belonging to two or more different client units can be 
cross-coupled, from request to request In one session, 
or from session to session. That is, it is also possible 
that a first client unit carries some properties which are 
relevant also for other client units. For example, the con- 
tent data request to be analysed on the server side may 
contain additional information about a backup client up 
to be used in case of failure of the first client unit. Fur- 
thermore, there may be clusters of linked client units 
such that some information may Indeed be common to 
a sub-group of client units CU. This could for example 
be the case if all client units CU of a company have the 
same type of device, such that a device identification 
could be commonly assigned for ail client units in the 
server on the basis of only a single content data request 
from a single client unit. 

[0083] Furthermore, in accordance with yet another 
embodiment, it is also possible that the server evaluates 
or processes all properties of ail client units together to 
obtain common information for all client units. 
[0084] Furthermore, it is also possible that an instruc- 
tion data set of a first client unit Is not flexibly adapted 
or varied I accordance with the properties relating to 
such a first client unit but It is also possible that this first 
client unit instruction data set is varied In accordance 
with properties obtained for one or more other client 
units. 

[0085] Therefore, in the analysing and storage oper- 
ations S4, S5 the content data request property provider 
unit CDPP will analyse and store properties separately 
for different client units CU such that the property pro- 
vider unit CDPP, when prompted to provide specific 
properties in the profiling procedure, will be capable of 
providing properties on a client unit specific basis. 
[0086] A skilled person will understand that a content 



data request CDRQ, e.g. the HTTP-request shown in 
Fig. 8a, can comprise a large number of Identifications 
and parameters from which the property provider unit 
CDPP can analyse and extract the desired properties. 

5 Such properties may be categorised as client unit relat- 
ed properties DPP, RQRM, CMDPP and content data 
related properties RESPP, as shown In Fig. 8a. 
[0087] Therefore, in accordance with one embodi- 
ment of the content data request property provider unit 

io CDPP shown in Fig. 8a can comprise a device property 
provider DPP for providing for each client unit CU as 
said client unit related properties device properties 
about the client unit device CU, a resource property pro- 
vider RESPP for providing as said content data related 

15 properties resource properties about data content re- 
sources CORES and about the content data, a content 
data requesting unit property provider RQRM for provid- 
ing as said client unit related properties about the con- 
tent data requesting unit RQRM used at the client units, 

20 and a command property provider CMDPP for providing 
as said client unit related properties also properties 
about command Issued at the client units CU. The pro- 
vider unit CDPP can comprise a first property memory 
MEM1 for client unit related properties and a second 

25 memory MEM2 for content related properties. 

[0088] In accordance with one embodiment, the de- 
vice properties are generally used in connection with the 
client device. Such properties refer to things as the dif- 
ferent display sizes on the device. In accordance with 

30 one embodiment, the resource properties can cover 
properties, which are assigned to a requested document 
or more generally to a content data resource. Such prop- 
erties, for example, include the various document types 
(Star Office documents, Star Office writer, Star Office 

35 calculator or other document formats such as PDF as 
well as customized content types used for folders, for 
example). 

[0089] As explained above, since the content data re- 
quest unit RM can use different browsers, e.g. Netscape 
40 Browser 4.X and the Internet Explorer, the type of con- 
tent data requesting unit as one of said client unit related 
property can be identified by request header parameters 
in the content data request message CDRQ. 
[0090] Finally, it is possible to supply additional infor- 
ms mation with each request in order to have custom com- 
mands run. These additional details are contained as 
request parameters in the request message. This is an- 
other example for the client unit related properties re- 
garding issued commands. 
so [0091 ] As already briefly explained above, in order to 
avoid having to transfer a large number of additional pa- 
rameters, in particular with respect to the request pa- 
rameters, request header parameters, resource proper- 
ties and device properties, the properties orproperty pa- 
55 rameters can be collected and stored as attrtoutes in 
one HTTP session, or can also be stored, updated and 
reused from session to session and the properties my 
also be cross-related between different client units. In 
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this way, It is not necessary to send all the parameters 
with subsequent requests, and Instead of this the details 
of previous requests can be accessed in memories 
MEM1.M EM2 separately for each client unit (That is the 
operations S4 ( S5 in Fig. 7a can be skipped with the 5 
operation S4 1 ). 

[0092] A skilled person will realize that a great variety 
of properties depending on the type of request message 
and the type of processing in the provider unit CDPP 
can be stored in the memories and that the aforemen- 10 
tioned examples are only examples for the device prop- 
erties, resource properties, request header parameters 
and request parameters based on which such proper- 
ties can be determined. 

[0093] Finally, at the junction® in Fig. 7a, the content m 
data request property provider unit CDPP is in a position 
to provide one or more content data request properties 
CDPP determined on the basis of one or more content 
data requests made by separate client units CU. This 
can be done on the basis of a first or of several content 20 
data requests CDRQ. 

[0094] Hereinafter, we explain how these properties, 
determined in Fig. 7a, are used by the profiling service 
in order to set up a flexible instruction or screen format. 

25 

FORMAT ADAPTION PROCEDURE USING A TREE 
STRUCTURE 

[0095] Asdescribedabove.atthejunction® thecon- 
tent data request property provider unit CDPP is in a 3D 
position to provide properties whenever it is requested 
to do so. Now, It will be explained how these properties 
are used to build up a flexible instruction or screen for- 
mat. 

[0096] As illustrated in Fig. 5d, the instruction format 35 
set up unit IFSET prepares an instruction data set IDS 
having a particular instruction format IF and consisting 
of a plurality of instruction element data sets IEDS each 
representing a particular instruction element IE of the 
instruction format IF and generated by one or more in- 40 
structlon element generating units CO of the instruction 
format set up unit IFSET. The fact that each instruction 
element generating unit will produce a separate instruc- 
tion element and thus a separate instruction element da- 
ta set is also apparent from Fig. 6 which shows the re- « 
iationship between the set up unit IFSET and a tree 
structure in an Instruction format configuration file 
IFCFG of the screen registry IREG. 
[0097] In particular, Fig. 6 shows details of the Instruc- 
tion format configuration file IFCGFshown in Fig. Sdand so 
In Fig. 8. In particular, the configuration file IFCFG con- 
tains a tree data structure TRE consisting of a plurality 
of Instruction format nodes NO, N1, N2,; H1,H1,1, H1 .2, 
H1.3. Each instruction node NO indicates a particular 
combination of instruction elements IE1 , IE2; IE1 , IE2, » 
IE3, IE4, IE5 associated with each node. Furthermore, 
each node has associated with it a node selection crite- 
rion N1SEL. H1SEL, N2SEL, H1.1SEL, H1.2SEL, 



H1 .3SEL The top node NO which is the entry node into 
the tree structure TRE provides a default instruction for- 
mat, i.e. also the entry node NO has associated with it a 
number of instruction elements, however, since this is 
the node where the search procedure is started, there 
is no need to assign to it a special selection criterion, 
because it is always selected. 
[0098] As shown with the double-arrow in Fig. 6, each 
instruction element IE is associated with a correspond- 
ing instruction element generating unit CO in the instruc- 
tion format set up unit IFSET 
[0099] In the operation S7, as shown in Fig. 7b, the 
instruction format selection unit IFSEL searches the tree 
data structure TRE with the determined content data re- 
quest properties CDPP and it selects an instruction for- 
mat node H1 .1 whose associated node selection condi- 
tion H1 .1 SEL matches said determined content data re- 
quest properties CDPP. 

[01 00] In accordance with one embodiment, the con- 
tent data request property provider unit CDPP provides 
all the properties before the actual searching operation 
in S7, namely with the operations S3, S4, S5 and S6 
before the actual search operation starts. 
[0101] In accordance with another embodiment, the 
instruction format selection unit IFSEL sequentially 
goes from node to node (as will explained below with 
more details) and will at each node look at its selection 
criterion N1SEL, N2SEL .... and only when performing 
the special test as to whether or not the criterion is ful- 
filled, It will ask or inquire at the property provider unit 
CDPP to provide a certain property of interest which 
needs to be compared with one of the properties re- 
quested in the selection criterion. 
[01 02] In the latter embodiment, the provider unit will 
on request provide the properties such that processing 
time and memory space can be saved since there Is no 
requirement to always keep all properties that could 
possibly be of Interest in the memories MEM1 , MEM2. 
[0103] After finding the appropriate node and by doing 
so also finding the appropriate instruction element gen- 
erating units CO relating to the indicated instruction el- 
ements, in operation S8 shown in Fig. 7b the instruction 
data set IDS is prepared by executing the instruction el- 
ement generating units CO of the selected instruction 
format node NO, Thus, after the operation S8 the com- 
plete instruction data set has been flexibly set up by unit 
of only executing generation units CO, which have been 
found on the basis of the properties of the content data 
request, i.e. on the basis of searching the tree with the 
properties to find a matching criterion in one of the 
nodes. 

[0104] Therefore, this generated Instruction data set 
IDS can now be sent from the server unit to the client 
unit in operation S9, S10 (corresponding to the opera- 
tions ST6, ST7 in Fig. 3) and the user can display or use 
the instruction data set IDS In the operation and if more 
content data is requested (YES) in the operation S12 
the procedure is started anew with the operation S2 in 
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Fig. 7a (operations S10, S11, S1 2 correspond to the op- 
erations ST7, ST8 t ST9 in Fig. 3). If no more content 
data needs to be requested the communication link CL 
is closed in the operation S13 (corresponding to opera- 
tion STIOin Fig. 3). 

[0105] The examples in Fig. 8b, 8c related to the case 
where, for example, the node N1 and the node H1.1 
were selected in the selection procedure shown in Fig. 
8. 

[01 06] As will be noted from Fig. 8b, the lower diagram 
is similar to the screen diagram shown in Fig. 4. How- 
ever, It has been differently set up via the flexible screen 
or instruction format adaption by the screen/instruction 
registry IREG of the invention as explained above with 
the selection procedure in Fig. 6 and 7b. That is, whilst 
in Fig. 4 the screen format IF or the format of the data 
set was fixed and completely independent of the prop- 
erties, the screen format IF shown in Fig. 8b was select- 
ed by specially searching forthe node N1 with properties 
which match the selection criterion N1SEL For exam- 
ple, the instruction element generating units C01 , C02 
could be responsible for generating the log-in window 
and the logo shown in the lower half of Fig. 8b. The up- 
per half in Fig, 6b shows the logical generation of this 
adaptive screen format IF. Therefore, whilstthe screens 
in Fig. 8b and Fig. 4 look very similar, they have been 
generated on the basis of different procedures, in par- 
ticular, the screen in Fig. 8b was generated by executing 
special generation units of a specially selected node N1 . 
[0107] Likewise, the example in Fig. 8c could be an 
example for arriving at the node H1 .1 in Fig. 6. As shown 
in Fig. 6, if the selection criterion H1.1SEL Is fulfilled, 
then the instruction element generation units C01 , C02, 
C03, C04, COS are executed for forming the editing 
screen shown in the lower half of Fig. 8c. The upper half 
in Fig. 8c again shows the instruction data set having 
the particular format IF together with the instruction el- 
ements IE 1, 1 £2, IE3, IE4, IE5. 
[0108] As will now be apparent from the above de- 
scription, the screens obtained, for example, in Fig. 8b 
and 8c have been generated flexibly, namely dependent 
on the properties which match a particular selection cri- 
terion of a node In the tree structure TRE. Another em- 
bodiment of the invention, where not only the instruction 
element generation units CO are determined in the tree 
structure TRE but also the positions are determined into 
which these instruction element generation units will in- 
sert their data wit) be described further below. 
[0109] The tree structure of nodes can, In accordance 
with one embodiment, already be stored permanently in 
the configuration file, to be used commonly for all client 
units whenever they send a content data request mes- 
sage with appropriate parameters allowing e.g. the 
property determination. 

[0110] in accordance with another embodiment, it is 
possible to set a new tree structure e.g. when a new 
request message is received in the server unit. This new 
tree structure is then used either oniy for the client unit 



which issued the request or for ail client units. 
[0111] In accordance with yet another embodiment, it 
is also possible that the tree structure is flexibly set, i.e. 
set In accordance with the determined properties. Thus, 
5 one of more appropriate tree structures can be loaded 
into the processor (i.e. one of several XML flies contain- 
ing such a tree structure). 

[0112] Furthermore, in accordance with yet another 
embodiment, it is also possible that there is a cross-con- 

10 nection or cross-link between several pre-stored tree 
structures. In this case, for example, if the procedure 
finds a valid node, i.e. a node whose selection condition 
is fulfilled by the enquired and provided properties, then 
a switch could be made from this node (called a tree 

15 switch node) to a node of another different tree structure 
whose nodes are subsequently searched. It is also pos- 
sible, during the tree search procedure, to jump back 
and forth between two or more available tree structures. 
[0113] Next, we will first describe a more particular 

20 embodiment how the procedure runs through the tree 
structure TRE in order to find the appropriate node. 

FINDING AN APPROPRIATE CHILD NODE 

25 [0114] Hereinafter, the selection procedure P1, P2, 
P3, P4, P5, P6 executed in the operation S7 in Fig. 7b 
will be explained with more detail in Fig. 9. 
[01 1 5] In the operation S71 the Instruction format se- 
lection unit IFSEL starts the search at the root instruction 

30 format node RNO. In the operation S72 the selection 
unit IFSEL checks all nodes N1, Ht, N2... depending 
from the root node NO. As shown in Fig. 6, the currently 
available content data request properties failed to match 
the criterion N1SEL of the node N1 and therefore, the 

35 procedure next checks the selection criterion H 1 SEL of 
the next depending node H1 (see the processing flow 
P1 , P2, P3). When checking all the nodes N1 , H1 , N2 
In theoperatlon S72, the instruction format selection unit 
IFSEL requests from the property provider unit CDPP 

40 for the current contents data request CDRQ a property 
relating to a property name parameter NME (explained 
with more details below) or a node selection condition 
of the respective next node. 

[0116] tf no node with a matching criterion is found in 
45 the operation S73, then the procedure goes to the op- 
eration S8 in Fig. 7b. The operation S8, the respective 
generation units CO associated with the root node RNO 
are executed because, although the root node RNO has 
not associated with it a selection criterion, it also is as- 
50 sociated with some instruction elements IE and thus 
with some instruction element generation units CO. As 
will be understood below, the root node can produce a 
default instruction format with an instruction template in 
the plurality of instruction element positions into which 
55 the instruction element generating units CO can insert 
instruction element data sets when they have been ex- 
ecuted. 

[0117] Returning to Fig. 9, if a matching criterion, i.e. 
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a next valid node, is found in the operation S73, the pro- 
cedure goes to the operation S74 where the next node 
with the matching criterion H1 is approached, in the op- 
eration S75, it is tested whether the node A1 is a child 
node, i.e. whether there are any further nodes depend- 
ing from it or not. If there are no further nodes depending 
(NO in the operation S7S), then the instruction element 
generation units CO associated with the instruction el- 
ements IE of the child node H1 are executed by the serv- 
er processing unit in the operation S8. 
[0118] If there are still more nodes depending from the 
node H1, as is the case In Fig. 6, then the selection unit 
checks further dependent nodes H1 .2, H1 .2, H1 .3 in the 
operation S76. Then again operation S73 is carried out 
in order to find whether a matching node is found. As 
shown in Fig. 6, the loop of operations S73, S74, S75, 
S76 is carried out once more (paths P4, P5, P6; the dot- 
ted line always indicates when no match was found at 
the respective depending node). Thus, the procedure 
selects the node H1.1. in levei 2, because it is a child 
node (no further depending nodes) and the selection cri- 
teria was matched by the provided properties. 
[01 1 9] Depending on the depth of the tree, up to n it- 
erations In the loop may have to be earned out until a 
valid child node is found. 

INHERITING FEATURES FROM A PREVIOUS NODE 

[0120J Above it was described that in a case where 
no further depending nodes are detected and the selec- 
tion criterion is fulfilled, a screen or instruction format 
will be set up with the corresponding generation units. 
In this case, the generation units are those generation 
units belonging to the node, which have been found with 
a matching criterion. That is, the instruction format and 
thus the instruction data set will be fully generated by 
the generation units belonging to this particular node. 
[0121] However, in accordance with another embod- 
iment, a depending node may also inherit some of the 
instruction element or instruction element generation 
units from a previous node through which the selection 
procedure ran. 

[01 22] Such an inheritance function is particularly ad- 
vantageous for embodiments In which the instruction 
format is composed of two parts, namely of an instruc- 
tion template ITEMP and a plurality of instruction ele- 
ment positions IEP into which the respective instruction 
element generating units CO Insert instruction element 
data sets which in combination form the instruction data 
set IDS. The purpose of such a two part division of the 
Instruction format IF may easily be understood with ref- 
erence to the example in Fig. 8c. 
[0123] That is, in Fig, 8c a first set of instruction ele- 
ments may merely be responsible for forming a so- 
called instruction template (as also shown in Fig. 8b). 
As explained, this instruction template ITEMP will again 
be generated by one or more associated Instruction el- 
ement generating units, i.e. these generation units will 



set up a template with a number of placeholders IE1 , 
IE2, IE3, IE4 which define the positions where later on 
further instruction element generating units will insert 
content data retrieved from the data base D8. 
* [0124] The difference between the template part and 
the second part, which inserts the data, can be under- 
stood with an example. For instance, the template 
ITEMP shown in Fig. 8c may set up the positions where 
in principle yellow (IE1), green (IE2) and red (IE3) cards 
10 will be placed. The template only specifies the principal 
positions where they should be located. Now, In a sec- 
ond part an actual yellow, green and red card is placed 
in the instruction or screen elements IE1, IE2, IE3, for 
example by an appropriate instruction element genera- 
's tion unit relating to yellow, red and green cards. That is, 
in a second part the instruction element generation units 
will insert the respective "yellow", "red" and "green" da- 
ta. 

[0125] On the basis of understanding the division into 

20 an instruction template and an element data insertion at 
the placeholders (provided by the template), the func- 
tion of Inheritance can easily be understood. Of course, 
the root node RN0 in Fig. 6 has a default screen or in- 
struction template into which instruction elements of the 

25 same root node will insert data if no further depending 
valid nodes are detected (NO in the operation S73). 
[0126] On the other hand, the node N2 in Fig. 6, which 
is a child node, may not contain a screen template but 
only some instruction element generation unit to be 

30 used in connection with the node N2. In this case, the 
template would be missing and the Instruction element 
generation units would not know at which position to in- 
sert their data. Therefore, the node N2 inherits the 
screen or instruction template from the root node NO if 

35 it itself cannot provide such a template. 

[0127] As another example, the selected child node 
H1 .1 may not have an instruction template specification 
but the previous node H1 one levei up contains such a 
template specification. As mentioned before, the only 

^0 reason why the node H1 was not selected is because 
there where further dependency nodes. On the other 
hand, the selection criterion was indeed fulfilled with the 
currently available property. Therefore, in case a screen 
template or Instruction template is missing at a valid 
child node, the selection procedure runs back through 
all previous valid nodes until it finds a valid node (i.e. a 
node with a matching criterion) which contains the nec- 
essary screen or instruction template. For example, it 
may be the case that also the node H 1 has itself no tem- 

50 plate specification such that in this case the default tem- 
plate specification of the node NO, which wilt always be 
valid, Is used. Thus, the screen template further up the 
tree" is passed on/to (inherited by) nodes "further down 
the tree." 

55 [01 28] According to another embodiment, it is indeed 
envisaged that the set up of an instruction format is not 
limited to a first part of a template and a second part of 
inserting the data at the template placeholder positions. 
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It could be imagined that an instruction format or screen 
format consists of a large number of different parts and 
also In this case a part specified in a previous node, 
which has been detected as valid can be inherited down- 
wards to any child node. 

[0129] in accordance with another embodiment, it is 
of course also possible that several parts or specifica- 
tions are inherited downwards to a child node. Thus, the 
inheritance procedure has a particular advantage that it 
is not necessary to perform all specifications in all nodes 
because specifications from higher nodes upwards can 
be taken over (inherited) at tower nodes. 
[0130] Speaking about the division of the instruction 
format In an Instruction template and a plurality of In- 
struction element positions, in accordance with one em- 
bodiment, when the instruction data set is a set of in- 
struction data for displaying a screen with a particular 
screen layout format on the client unit display unit DSP, 
the instruction template ITEMP is a screen layout tem- 
plate SCRN and said instruction element positions are 
placeholders on the screen into which the respective in- 
struction element generating units insert screen ele- 
ment data sets when they are executed. 
[0131] Alternatively, in accordance with another em- 
bodiment, when the Instruction data set IDS relates to 
a set of instruction date for controlling a device with a 
particular control command layout on the client unit CU, 
for example a robot, the instruction template HEMP is 
a command layout template and the Instruction element 
positions are command holders, Into which the instruc- 
: tlon element generating units insert command data sets 
when they are executed. 

[0132] Therefore, it should be understood that the 
concept of a template and the position holders is not re- 
stricted to data sets which use graphics data but can by 
used for any other data sets, which the user wants to 
use at the client unit for other purposes, such as control 
purposes, printing purposes etc. 

SCREEN TEMPLATE / SELECTION CRITERION / 
GENERATION UNITS - JAVA IMPLEMENTATION 

[0133] Hereinafter, with reference to Fig. 10a and Rg. 
10b another embodiment is described in which the se- 
lection unit IFSEL and the screen registry are imple- 
mented as XML files in JAVA. However, it should be not- 
ed that the usage of the screens, components, argu- 
ments, requirements and substitutions explained below 
are not restricted to an implementation in JAVA and cor- 
responding functions can be found in other implemen- 
tations. Therefore, the JAVA Implementation below only 
serves as a good example for Illustrating some further 
features and functions of further embodiments. In Fig. 
10a, 1 0b the same designation of nodes, selection cri- 
teria and instruction element generation units as in Fig. 
6 are used. A thick line in Fig. 10a illustrates a possible 
search scenario, similar to the path P1 , P6 in Rg. 6. 
[0134] As shown in Fig. 10a, the tree data structure 



comprises a plurality of nodes NO, for example the 
nodes NO, N1, N2; H1, H1.1, H1.2, H1.3 which are ar- 
ranged in a tree structure, i.e. from the node NO the 
nodes N1 , N2, H1 are branched off and in turn the nodes 
5 H1 .1 , H1 .2, H1 .3 are branched off from the node H1 . In 
this respect, the tree structure is similar to the one 
shown in Rg. 6. 

[0135] Furthermore, the tree structure comprises 
screens SCRN, components CO, arguments ARG and 

io possibly substitutions SUB (a substitution is, however, 
not shown in Fig. 1 0a because it is not needed here). 
[0136] As will be understood with reference to Fig. 
10b showing a JAVA implementation of the instruction 
format selection unit IFSEL, a screen SCRN Is basically 

15 the definition of the screen (instruction) template ITEMP. 
As can be seen from Rg. 10b, the root node RNOD de- 
fines a default screen with a JAVA server pages program 
"HTMLTemptate.jsp". Thereafter, there are two compo- 
nent names "title" and "background", which essentially 

20 correspond to Instruction element generating units CO 
used for building up the elements (placeholders) of the 
screen template. As mentioned above, a template is to 
be understood as providing a format together with in- 
struction element positions (placeholders) into which 

2S other instruction element generating units can then in- 
sert their data. 

[0137] The two component names are followed by an 
argument name "picture". Like normal arguments in any 
programming language, a value of this argument 

30 "$B ACKG ROUNDUP ICTU RE* is still undefined at this 
stage. When the actual screen template is executed, 
this value is set with a subprogram request via a substi- 
tution name, which is shown in Fig. 10d at the bottom. 
[0138] Furthermore, the screen template comprises a 

35 further component with a component name "error", 
wherein a program "/html/HTMLError.jsp" is executed 
when there is an error in the default screen template. As 
can be seen from comparing the code section for the 
node NO in Fig. 10b with the tree structure in Fig. 10a, 

40 the actual root node RNOD is defined by a screen, two 
components (wherein the second component has also 
an argument) and another component. The inclusion of 
the undefined argument is made by referring to a sub- 
stitution component "$BACKGROUND_PlCTURE", 

45 which is located at the node H 1 .3. As will be appreciated 
from Fig. 1 0a and Fig. 1 0b, the root node NO is the entry 
node into the tree structure TRE and therefore, there is 
no selection condition specified, i.e. there are no re- 
quirement types, which define these selection condi- 

so tions. 

[0130] Proceeding to node N1 , this node comprises, 
as shown In Rg. 10a, an operation, two requirements 
and a screen. As can be seen from Rg. 1 0b, an opera- 
tion is basically a logical combination of some sub-con- 
55 ditions, which are defined with the requirement type. 
Thus, the first requirement comprises a property type 
parameter "requestParameter" and further comprises a 
name "cmd". This property type parameter RE-TYP In- 
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dicates to the content data request property provider 
unit CDPP the type of property to be enquired. It should 
be noted that this Is not the property Itself but only the 
type of property, which Is looked for. The actual property, 
which is inquired, is the "CMD° (e.g. a command). The 5 
expected value of the inquired property of the type "re- 
questParameter" is "execute Jogln". The next require- 
ment checks for the type "execution Environment" the 
response for the name "loginBean". The expected value 
should be "0". Furthermore, the operation type, i.e. an 10 
operation condition, is specified for logically "AND" com- 
bining the results of the two requirements. Therefore, 
the node N1 will be selected if the "cmd" is equal to 
"execute Jogln" and the "loginBean" is equal "0". 
[01 40] Furthermore, In this case the node N 1 also de- « 
fines a screen template which is here called "/portal/ 
login" of the class "login", For example, this screen tem- 
plate could produce a login page as shown in Fig. 8b. 
As explained above, since the node N1 also comprises 
a screen template, It will not "inherit" the default screen 20 
template of the node NO. 

[0141] Furthermore, the node N2, which is also de- 
pending from the root node RNOD comprises one re- 
quirement and a screen. That is, also the node N2 is 
associated with a selection condition which checks for & 
name "cmd* to be having a value of "logout", if the node 
N2 Is selected, yet another screen template (here relat- 
ing to a logout screen) is selected. Therefore, if the node 
N2 is selected, because the return parameter from the 
property provider is "logout" , then also the node N2 will so 
define Its own screen template and will not Inherit a 
screen template from a node further above. 
[0142] The node definition with Its selection condition 
(requirement), template definition (screen template), 
logical combinations for the selection conditions (oper- 3s 
ation) and indications of Instruction element generation 
units (components) can, In accordance with one embod- 
iment of the Invention, be implemented as XML files with 
a JAVA code or JAVA implemented code as shown in 
Fig. 10b forthe main nodes NO, N1, N2. 40 
[0143] Fig. 10c and Fig. 10d show the definition of 
HTML nodes H1, H1.1, H1.2, H1.3. The definitions for 
these nodes In Fig. 10d, 10e are in the same format as 
the definition in Fig. 10b forthe main nodes. For exam- 
ple, the node H1 comprises operations and require- 4s 
mentB but it does not comprise a screen template. The 
node H1.1 includes a screen template Vhtml/HTML- 
LoginTlmplate.jsp" and other components and require- 
ments as shown In Fig. 10c and Fig. I0d. The node H1 
and the node H 1.1 will be selected If the correct proper- so 
ties are returned from the property provider, whenever 
a requirement type execution operation is to be checked 
within the respective nodes. 
[0144] In node HI .3 a special substitution name is in- 
cluded, i.e. this node H 1 .3 provides the subprogram for 55 
an inclusion of a file in the node NO. Thus, the argument 
type in the node NO can have cross-reference to the sub- 
stitution name in the node H1 .3. For example, in the 




node H1 .3 a special background Is set forthe screen. 
[0145] Among the nodes H1, H1.1, H1.2, H1.3 only 
the nodes H1 .1 and H1 .2 have a screen template defi- 
nition. Therefore, should these nodes be selected dur- 
ing the selection procedure going through the tree struc- 
ture, then these nodes will not inherit a screen template 
from one of the preceding valid nodes (valid = the se- 
lection condition was fulfilled but there where further 
child nodes to this node). 

[0146] Finally, Fig. 1 0f shows a tree structure for WML 
nodes and Fig. 1 0g-i show the content of the information 
or instruction format selection unit IFSEL in the WML 
case. The structure of this tree is In principle similar to 
the structure of the four described trees, such that no 
further discussion is necessary here. All files for the 
screen registry (a tree data structure) definition can be 
Implemented, in accordance with one embodiment of 
the invention, by XML files, as the skilled person will eas- 
ily realize from the JAVA code in Fig. 10b, Fig. 10d and 
Fig. 10e. 

[0147] The instruction format selection unit IFSEL 
can, according to one example in Fig. 10a, cany out a 
search procedure as the one shown in Fig, 6, namely 
along the search paths P1 , P2, P3, P4, P5, P6 in order 
to select the node H1.1. If thenodeH1.1 is selected be- 
cause the requirement types are fulfilled, then this node 
happened to comprise Its own screen template "login, 
screen" and therefore in this search procedure the 
screen of the last above node is selected. In principle, 
the selection procedure will run through the nodes in a 
hierarchical order from level to level. However, It is of 
course possible that afterchecking the node H1 , notthe 
node H1 .2 is first checked but the node H1 .1 . A skilled 
person can, on the basis of the above teachings, derive 
many different search scenarios by running through the 
tree structure in order to find a valid node. 
[01 48] Once the valid node has been found, the com- 
ponent types will indicate a respective instruction ele- 
ment generating unit and the component is executed In 
order to fill the placeholders defined with the screen tem- 
plate with the respective data. Thus, once a node has 
been selected, the specific components generate the fi- 
nal instruction data set to be returned to the client unit. 
[0149] Therefore, it can now be understood that with 
the flexible set up of the tree structure in the configura- 
tion file, any type of flexible set up, for example for a 
screen, can be performed, essentially based on the Idea 
of forming the screen registry as shown In Fig. 1 0a. The 
screen registry reads its data from an XML file or the 
configuration and obtains a tree of nodes with their re- 
quirements (conditions). Thus, each node refers to a 
possible screen and a screen is formed by a template 
jsp or a servlet with a set of argument servlets, as shown 
in Fig. 10b. The template describes at what positions 
(placeholders) the arguments are inserted in the tem- 
plate In the process of creating the response. The re- 
quirements describe in terms of client capabilities, the 
URL, request parameters etc., i.e. the above-described 
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code section for providing one or more content 
data request properties of the content data re- 
quest made by a client unit; 

5 b) an instruction format set up code section for 
preparing an Instruction data set having the in- 
struction format and consisting of a plurality of 
instruction element data sets each represent- 
ing a particular instruction element of the In- 
fo struction format and generated by one or more 

instruction element generating code sections of 
said instruction format set up code section; 

c) an Instruction format configuration file con- 
's tainlng a tree data structure consisting of a plu- 
rality of instruction format nodes, each instruc- 
tion format node indicating a particular combi- 
nation of instruction elements constituting a 
particular instruction format and having associ- 

6 ated with it a node selection criterion; 

d) an instruction format selection code section 
for searching said tree data structure with the 
determined content data request properties 

& and for selecting an instruction format node 

whose associated node selection condition 
matches said determined content data request 
properties; and 

so e) said instruction format set up code section 

preparing the instruction data set to be sent to 
the client unit by executing the instruction ele- 
ment generating code sections of the selected 
instruction format node. 

35 

2) A server unit according to item 1 , 
wherein 

said content data request property provider code 
section analyses said content data request to pro- 
^0 vide one or more of client unit related properties and 
content data related properties. 



properties, which node to use for which request. 
[01 50] Therefore, the present invention can adaptive- 
ly and flexibly create instruction formats, e.g. for the set 
up of a screen or the set up of an instruction data set, 
dependent on some properties derived from the content 
data request sent by the client unit. Thus, the actual 
servlets or Jsps do not have to be touched and still a 
flexible way of setting up the instruction formats can be 
achieved. 

SOFTWARE / HARDWARE EMBODIMENTS 

[0151] Furthermore, the features in the processing 
operations of the above-described embodiments may 
be realized by dedicated hardware or may be realized 
as programs including code instructions executed on 
data processing units. It is further possible that parts of 
the above processing operations are carried out in hard- 
ware, whereas other processing operations are carried 
out using software. 

[01 52] It is further noted that a computer program pro- 
duced stored on a computer readable storage medium 
can comprise code units adapted to carry o ut on a server 
side or on the client side respectively the operations de- 
scribed above. Further, a computer program product 
may be provided comprising the computer readable me- 
dium. 

[0153] A computer program can have instructions 
adapted to carry out at a server side or a client side the 
above-described operations. Furthermore, a data carri- 
er for a server side or a client side has a computer read- 
able storage code embodied therein, which carries out 
one or more of the respective above-described opera- 
tions and units in the server and the client. A computer 
readable medium can be a magnetic or optical or other 
tangible medium on which a program is recorded, but 
can also be a signal, e.g. analogue or digital, electro- 
magnetic or optical, In which the program is embodied 
for transmission. 

[0154] Furthermore, the client unit may be not only a 
computer, but according to another embodiment it can 
be a general purpose data processing device, a mobile 
device such as a mobile telephone such as one, which 
is WAP compatible or a mobile organizer, a navigation 
device or a cash point. 

FURTHER EMBODIMENTS {CODE SECTIONS) 

[0155] According to other embodiments, aserverunit 
may be constituted as follows: 

1) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data set in a particular 
instruction format in response to a content data re- 
quest, comprises: 

a) a content data request property provider 



3) A server unit according to item 2, 
wherein 

said content data request property provider code 
section includes: 

a device property provider for providing for 
each client unit as said client unit related prop- 
erties device properties about the client unit de- 
vice; 

a resource property provider for providing as 
said content data related properties resource 
properties about data content resources pro- 
viding the content data; 

a content data requesting code section proper- 
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ty provider for providing as said client unit re- 
lated properties properties about the content 
data requesting code section used at the client 
units; and 

5 

a command property provider for providing as 
said client unit related properties properties 
about commands Issued at the client units. 

4) A server unit according to Item 2, w 
wherein 

said content data request property provider code 
section includes a first property memory for client 
unit related properties and a second memory for 
content data related properties. « 

5) A server unit according to item 4, 
wherein 

said content data request property provider code 
section anaryses a first content data request to ob- 20 
tain said client unit related properties and said con- 
tent data related properties, wherein at the arrival 
of any subsequent content data request in the same 
session said content data request property provider 
only accesses said first memory or said second 25 
memory to provide said client unit related properties 
and/or said content data related properties. 

6) A server unit according to item 1 , 

wherein 30 
said node selection condition comprises one or 
more node selection requirements including at least 
one property name parameter and an expected 
property; wherein 

35 

said instruction format selection code section 
is adapted for starting the search at the root in- 
struction format node; wherein 

said instruction format selection code section 40 
is adapted for requesting from the property pro- 
vider code section for the current content data 
request a property relating to the property name 
parameter of a node selection condition of 8 
next Instruction format node; wherein 45 

said instruction format selection code section 
is adapted for branching to said next instruction 
format node, if the provided property match with 
the expected property. 50 

7) A server unit according to item 6, 
wherein 

said node selection requirement further comprises 
a property type parameter indicating the type of 55 
property to be enquired at the property provider. 

8) A server unit according to item 6, 



wherein 

said node selection condition further comprises one 
or more operation conditions for logically combining 
the results of two or more requirements. 

9) A server unit according to item 1 , 
wherein 

the Instruction format formed by the instruction ele- 
ments of a root instruction format node of said tree 
data structure is a default instruction format 

10) A server unit according to item 9, 
wherein 

the default instruction format is an instruction format 
with an Instruction template and a plurality of in- 
struction element positions into which the instruc- 
tion element generating code sections insert in- 
struction element data sets when they are execut- 
ed. 

11) A server unit according to item 1 , 
wherein 

said instruction format includes an instruction tem- 
plate and a plurality of instruction element positions 
into which the instruction element generating code 
sections insert instruction element data sets when 
they are executed. 

12) A server unit according to item 1 , 
wherein 

said instruction element generating code sections 
include a component name of a component to be 
executed. 

13) A server unit according to item 12, 
wherein 

said instruction element generating code sections 
further include an argument name with a substitu- 
tion name of a substitution component located at a 
different node. 

14) A server unit according to item 11 , 
wherein 

said instruction data set is a set of instruction data 
for displaying a screen with a particular screen lay- 
out format on the client unit, wherein the instruction 
template is a screen layout template and said in- 
struction element positions are place holders into 
which the instruction element generating code sec- 
tions (C01-C05) insert screen element data sets 
when they are executed. 

15) A server unit according to item 11 , 
wherein 

said instruction data set is a set of instruction data 
for controlling a device with a particular control com- 
mand layout format on the client unit, wherein the 
instruction template is a command layout template 
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and 

said Instruction element positions are command 
holders into which the instruction element generat- 
ing code sections insert command data sets when 
they are executed. s 

16) A server unit according to item 1 , 
wherein 

said client unit and said server unit are JAVA based 
code sections, wherein said Instruction format con- 10 
figuration file containing said tree data structure is 
a JAVA XML file. 

17) A server unit according to item 17, 

wherein is 
said Instruction element generating code section is 
a JAVA servlet or a JAVA server pages program. 

1 6) A data carrier for a server side having computer 
readable storage code embodied therein which 20 
comprises: 

a) a code section for providing one or more con- 
tent data request properties of the content data 

. request made by a client unit; £5 

b) a code section for preparing an instruction 
data set having the instruction format and con- 
sisting of a plurality of instruction element data 
sets each representing a particular Instruction 30 
element of the instruction format and generated 

by one or more Instruction element generating 
code sections of said code section for preparing 
an Instruction data set; 

35 

e) a code section containing a tree data struc- 
ture consisting of a plurality of instruction for- 
mat nodes, each Instruction format node indi- 
cating a particular combination of instruction el- 
ements constituting a particular instruction for- to 
mat and having associated with it a node selec- 
tion criterion; 



or more server units according to one or more of 
items 1 -1 7 and one or more client units. 

20) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data set in a particular 
Instruction format in response to a content data re- 
quest, comprising: 

c) an instruction forma! configuration file con- 
taining a tree data structure consisting of a plu- 
rality of instruction format nodes, each instruc- 
tion format node indicating a particular combi- 
nation of instruction elements constituting a 
particular instruction format and having associ- 
ated with it a node selection criterion; and 

d) an Instruction format selection code section 
for searching said tree data structure with con- 
tent data request properties relating to a con- 
tent data request sent by the client unit and for 
selecting an instruction format node whose as- 
sociated node selection condition matches said 
content data request properties. 

21) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data set in a particular 
Instruction format, wherein the server unit is adapt- 
ed to make the instruction format of the instruction 
data set flexibly dependent on the capabilities of the 
client unit and/or the properties of the content data. 

22) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data 6et in a particular 
instruction format, wherein the server unit is adapt- 
ed to make the generation and retrieval of the con- 
tent data and its format flexibly dependent on prop- 
erties of the client unit and/or the properties of re- 
source code sections which provide said content 
data. 



d) a code section for searching said tree data 
structure with the determined content data re- *s 
quest properties and for selecting an Instruction 
format node whose associated node selection 
condition matches said determined content da- 
ta request properties; and 

so 

e) said code section for preparing an instruction 
data set being adapted for preparing the in- 
struction data set to be sent to the client unit 
executing the instruction element generating 
code sections of the selected instruction format ss 
node. 

19) A data communication system comprising one 



23) A server unit according to item 22, 
wherein 

said server unit comprises, for the flexible genera- 
tion and retrieval of the content data, a selection 
code section adapted to select from a number of 
instruction format templates a particular Instruction 
format template dependent on client properties and/ 
or resource properties, wherein said template de- 
scribes at what places in the instruction data set 
particular instruction elements can be placed; and 
one or more instruction element generating code 
sections adapted for inserting content data in the 
places indicated in the instruction format template; 
wherein 

the selection code section also selects the one or 
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more Instruction element generating code sections 
(n accordance with the client capabilities or re- 
source capabilities, from several available instruc- 
tion element generating code sections. 

24) A server unit of a data processing system In 
which one or more client units are provided by the 
server unit with an instruction data set In a particular 
instruction format, wherein the server unit compris- 



a selection code section adapted to select from 
a number of Instruction format templates a par- 
ticular instruction format template dependent 
on client properties and/or resource properties, ' * 
wherein said template describes at what places 
in the instruction data set particular instruction 
elements can be placed; and 

one or more instruction element generating 20 
code sections adapted for inserting content da- 
ta in the places indicated in the instruction for- 
mat template; wherein the selection code sec- 
tion also selects the one or more instruction el- 
ement generating code sections in accordance 25 
with the client capabilities or resource capabil- 
ities, from several available instruction element 
generating code sections. 

25) A server unit of a data processing system in so 
which one or more client units are provided by the 
server unit with an Instruction data set in a particular 
instruction format, wherein the server unit is adapt- 
ed to make the instruction format of the instruction 
data set flexibly dependent on the properties of the 35 
client unit and/or the properties of the requested 
content data obtained by a content data request 
property provider code section which is adapted to 
analyse a content data request from the client unit 

to provide said one or more client unit related prop- *o 
erties and content data related properties. 

26) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data set in a particular 45 
instruction format, wherein the server unit is adapt- 
ed to make the instruction format of the instruction 
data set flexibly dependent on client unit related 
properties stored in a first property memory and/or 
content data related properties stored in a second so 
memory. 

27) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data set, wherein the 55 
server unit is adapted to make the provision of the 
instruction data set dependent on searching a tree 
structure in a configuration file with some client unit 



related and/or content data related properties, 
wherein each node in the tree structure generates 
the instruction data set In a different instruction for- 
mat. 

28) A server unit of a data processing system In 
which one or more client units are provided by the 
server unit with an instruction data set, wherein the 
server unit is adapted to make the provision of the 
instruction data set dependent on searching a tree 
structure in an XML configuration file with some cli- 
ent unit related and/or content data related proper- 
ties, wherein each node In the tree structure gener- 
ates the instruction data set in a different Instruction 
format with a screen template generated by a tem- 
plate JSP (JAVA Server pages) or a servlet with a 
set of argument serviets and describing at what po- 
sitions the arguments are to be inserted in the tem- 
plate. 

29) A server unit according to item 27, wherein said 
tree structure is generated separately for each ses- 
sion between the client unit and the server unit. 

30) A server unit according to item 27, wherein said 
tree structure is generated once and independently 
for each session between the client unit and the 
server unit. 

31) A server unit according to item 27, wherein said 
tree structure is generated dependent on client-re- 
lated properties and/or content data properties. 

32) A server unit of a data processing system in 
which one or more client units are provided by the 
server unit with an instruction data set, wherein the 
server unit is adapted to determine client unit relat- 
ed properties and content data related properties 
by analysing a content data request form the client 
unit. 

INDUSTRIAL APPLICABILITY 

[01 56] As was explained above, the invention is usa- 
ble in a data communication system, in which a server 
and at least one client unit perform a data communica- 
tion in order to provide the client unit with an instruction 
data set in a flexible manner, in particular dependent on 
properties, which are derivable from the content data re- 
quest sent by the client unit. Although heretofore some 
references were made to the servers and clients imple- 
mented in a JAVA environment, it should be noted that 
the invention is equally well applicable to any other data 
communication system, tn which a main computer and 
a sub-computer communicate. The invention is also not 
restricted to the case, where the client is a computer and 
the invention can in particular be used in environments, 
where the client unit is a mobile telephone such as a 
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WAP compatible mobile telephone. 
[0157J Furthermore, it should be noted that the 
present invention is not limited to the specific embodi- 
ments described herein and that a skilled person can 
carry out various modifications and variations on the ba- s 
sis of the teachings herein. In particular, the invention 
can comprise embodiments, which result from a combi- 
nation of features and operations, which have been de- 
scribed separately in the claims and in the specification. 
Therefore, the invention is only defined by the scope of 10 
the attached claims. 

[0158] Reference numerals in the claims only serve 
clarification purposes and do not limit the scope of these 
claims. 



Claims 

1 . A server unit (SERV) of a data processing system 
(SYS) in which one or more client units (CU) are %> 
provided by the server unit (SERV) with an Instruc- 
tion data set (IDS) in a particular instruction format 
(IF) in response to a content data request (CDRQ), 
comprising: 

25 

a) a content data request property provider unit 
(CDPP) for providing one or more content data 
request properties (CDPP) of the content data 
request (CDRQ) made by a client unit (CU); 

30 

b) an instruction format set up unit (IFSET) for 
preparing an Instruction data set (IDS) having 
the instruction format (IF) and consisting of a 
plurality of instruction element data sets (I EDS) 
each representing a particular Instruction ele- 35 
ment (I E) of the instruction format (IF) and gen- 
erated by one or more instruction element gen- 
erating units (CO, ARG, SUB) of said instruc- 
tion format set up unit (IFSET) ; 

40 

c) an instruction format configuration file 
(IFCFG) containing a tree data structure (TRE) 
consisting of a plurality of instruction format 
nodes (NO; NO, N1 , N2; H1 , H1 .1 , H1 ,2 t H1 .3;) t 
each Instruction format node (NO) Indicating a <s 
particular combination of instruction elements 

(IE) constituting a particular instruction format 

(IF) and having associated with it a node selec- 
tion criterion (OP, RE, VAL); 

50 

d) an Instruction format selection unit (IFSEL) 
for searching said tree data structure (TRE) 
with the determined content data request prop- 
erties (CDPP) and for selecting an instruction 
format node (I FNO) whose associated node se- ss 
lection condition ((OP, RE, VAL) matches said 
determined content data request properties 
(CDPP); and 



e) said instruction format set up unit (IFSET) 
preparing the instruction data set (IDS) to be 
sent to the client unit (CU) by executing the in- 
struction element generating units (CO, ARG, 
SUB) of the selected instruction format node 
(NO). 

2. A server unit (IERV) according to claim 1 , 
wherein 

said content data request property provider unit 
(CDPP) analyses said content data request 
(CDRQ) to provide one or more of client unit related 
properties (DPP, RQRM, CMDPP) and content data 
related properties (RESPP). 

3. A server unit (SERV) according to claim 2, 
wherein 

said content data request property provider unit 
(CDPP) includes: 

a device property provider (DPP) for providing 
for each client unit (CU) as said client unit re- 
lated properties device properties about the cli- 
ent unit device (CU) ; 

a resource property provider (RESPP) for pro- 
viding as said content data related properties 
resource properties about data content re- 
sources (CDRES) providing the content data 
(CD); 

a content data requesting unit property provider 
(RQRM) for providing as said client unit related 
properties properties about the content data re- 
questing unit (RQRM) used at the client units; 
and 

a command property provider (CMDPP) for 
providing as said client unit related properties 
properties about commands Issued at the client 
units (CU). 

4. A server unit (SERV) according to claim 2, 
wherein 

said content data request property provider unit 
(CDPP) includes a first property memory (MEM1) 
for client unit related properties and a second mem- 
ory (MEM2) for content data related properties. 

5. A server unit (SERV) according to claim 4, 
wherein 

said content data request property provider unit 
(CDPP) analyses a first content data request 
(CDRQ) to obtain said client unit related properties 
and said content data related properties, wherein at 
the arrival of any subsequent content data request 
(CDRQ) in the same session said content data re- 
quest property provider (CDPP) only accesses said 



21 




EP1220 



first memory (MEM 1 ) or said second memory to pro- 
vide said client unit related properties and/or said 
content data related properties. 

6. A server unit (SERV) according to claim 1 , s 
wherein 

said node selection condition (IELC) comprises one 
or more node selection requirements (RE) including 
at least one property name parameter (NME) and 
an expected property (NME); wherein w 

said Instruction format selection unit (IPS EL) is 
adapted for starting the search at the root in- 
struction format node (RNO); wherein 

15 

said instruction format selection unit (IFSEL) is 
adapted for requesting from the property pro- 
vider unit (CDPP) for the current content data 
request (CDRQ) a property relating to the prop- 
erty name parameter (NME) of a node selection *o 
condition (H1SEL) of a next instruction format 
node (NO); wherein 




1 1 . A server unit (SERV) according to claim 1 , 
wherein 

said instruction format (IF) includes an Instruction 
template (ITEMR SCRN) and a plurality of instruc- 
tion element positions (JEP) into which the instruc- 
tion element generating units (CO, ARG, SUB) in- 
sert instruction element data sets (I EOS) when they 
are executed. 

12. A server unit (SERV) according to claim 1 , 
wherein 

said instruction element generating units (CO, 
ARG, SUB) Include a component name (CO-NME) 
of a component to be executed. 

13. A server unit (SERV) according to claim 1 2, 
wherein 

said instruction element generating units (CO, 
ARG, SUB) further include an argument name 
(ARG-NME) with a substitution name (SUB-NAME) 
of a substitution component (SUB-CO; $) located at 
a different node (NO). 



said instruction format selection unit (IFSEL) is 
adapted for branching to said next instruction & 
format node (NO), if the provided property 
match with the expected property (NME). 

7. A server unit (SERV) according to claim 6, 
wherein 30 
said node selection requirement (RE) further com- 
prises a property type parameter (RE-TYP) Indicat- 
ing the type of property to be enquired at the prop- 
erty provider (CDPP). 

35 

8. A server unit (SERV) according to claim 6, 
wherein 

said node selection condition (N1S EL) further com- 
prises one or more operation conditions (OP) for 
logically combining the results of two or more re- *o 
qulrements (RE). 

9. A server unit (SERV) according to claim 1 , 
wherein 

the Instruction format (IF) formed by the instruction 45 
elements (IE) of a root instruction format node 
(RNOD) of said tree data structure (TRE) is a de- 
fault Instruction format (IDFLT). 

10. A server unit (SERV) according to claim 9, so 
wherein 

the default instruction format (IDFLT) is an Instruc- 
tion format (IF) with an instruction template (ITEMP, 
SCRN) and a plurality of instruction element posi- 
tions (IEP) into which the instruction element gen- ss 
erating units (CO) insert instruction element data 
sets (IE0S) when they are executed. 



14. A server unit (SERV) according to claim 11, 
wherein 

said instruction data set (IDS) is a set of instruction 
data for displaying a screen with a particular screen 
layout format (IF) on the client unit(CU), wherein the 
instruction template (ITEMP, SCRN) is a screen lay- 
out template (SCRN) and said instruction element 
positions (IEP) are place holders (IEP1-IEP5) into 
which the instruction element generating units 
(C01-C05) insert screen element data sets when 
they are executed. 

15. A server unit (SERV) according to claim 11 , 
wherein 

said instruction data set (I0S) is a set of instruction 
data for controlling a device with a particular control 
command layout format (IF) on the client unit(CU), 
wherein the instruction template (ITEMP, SCRN) Is 
a command layout template (SCRN) and said in- 
struction element positions (IEP) are command 
holders (IEP1-IEP5) into which the instruction ele- 
ment generating units (C01-C05) insert command 
data sets when they are executed. 

16. A server unit (SERV) according to claim 1 , 
wherein 

said client unit (CU) and said server unit (IERV) are 
JAVA based units, wherein said instruction format 
configuration file (IFCFG) containing said tree data 
structure (TRE) Is a JAVA XML file. 

17. A server unit (SERV) according to claim 17, 
wherein 

said instruction element generating unit (CO) is a 
JAVA servlet or a JAVA server pages program. 
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18. A method in a data processing system (DPS) 
for providing one or more client units (CU) by a serv- 
er unit (SERV) with an instruction data set (IDS) in 
a particular Instruction format (IF) in response to a 
content data request (CDRQ), comprising: s 

a) providing one or more content data request 
properties (CDPP) of a content data request 
(CDRQ) made by a client unit (CU) ; 

10 

b) preparing an instruction data set (IDS) hav- 
ing the instruction format (IF) and consisting of 
a plurality of instruction element data sets 
(IEDS) each representing a particular Instruc- 
tion element (IE) of the instruction format (IF); « 

c) searching a tree data structure (TRE) stored 
in an instruction format configuration file 
(IFCFG) and consisting of a plurality of instruc- 
tion format nodes (NO; NO, N1, N2; H1, H1.1, 20 
H1.2, H1.3; INCL), each instruction format 
node (NO) indicating a particular combination 

of instruction elements (IE) constituting a par- 
ticular instruction format (IF) and having asso- 
ciated with It a node selection criterion (OP, RE, 25 
VAL), with the determined content data request 
properties (CDPP) and for selecting an instruc- 
tion format node (IFNO) whose associated 
node selection condition ((OP, RE, VAL) match- 
es said determined content data request prop- 30 
erties (CDPP); and 

d) preparing the instruction data set (IDS) to be 
sent to the client unit (CU) by executing instruc- 
tion element generating units (CO, ARG, SUB) 35 
of the selected instruction format node (NO). 

19. A method according to daim 1 8, 
further comprising: 

40 

analysing a first content data request (CDRQ) 
to obtain and store properties in a memory 
(MEM1 . MEM 2) and, at the arrival of a subse- 
quent content data request (CDRQ) in the 
same session, accessing said memory (MEM 1 , 
MEM2) for providing said properties. 

20. A method according to claim 18, 
further comprising: 

30 

said node selection condition (tELC) compris- 
ing one or more node selection requirements 
(RE) including at least one property name pa- 
rameter (NME) and an expected property 
(NME); and 55 

starting the search at a root instruction format 
node (RNOD); 



requesting from a property provider unit 
(CDPP) for the current content data request 
(CDRQ) a property relating to the property 
name parameter (NME) of a node selection 
condition (IELC) of a next Instruction format 
node (NO); and 

branching to said next instruction format node 
(NO) if the provided property match with the ex- 
pected property (NME). 

21. A computer program product stored on a com- 
puter readable storage medium to be executed on 
a server side comprising code units adapted to car- 
ry out respectively all the steps of claim 18. 

23. A program having instructions adapted to carry 
out on a server side the following steps: 

a) providing one or more content data request 
properties (CDPP) of a content data request 
(CDRQ) made by a client unit (CU) ; 

b) preparing an instruction data set (IDS) hav- 
ing the Instruction format (IF) and consisting of 
a plurality of instruction element data sets 
(IEDS) each representing a particular instruc- 
tion element (IE) of the instruction format (IF); 

c) preparing an instruction format configuration 
file (IFCFG) containing a tree data structure 
(TRE) consisting of a plurality of instruction for- 
mat nodes (NO; NO, N1, N2; H1 f H1.1, H1.2, 
H1 .3; INCL), each instruction format node (NO) 
indicating a particular combination of instruc- 
tion elements (IE) constituting a particular in- 
struction format (IF) and having associated with 
it a node selection criterion (OP, RE, VAL); 

d) searching said tree data structure (TRE) with 
the determined content data request properties 
(CDPP) and for selecting an instruction format 
node (IFNO) whose associated node selection 
condition ((OP, RE, VAL) matches said deter- 
mined content data request properties (CDPP); 
and 

e) preparing the instruction data set (IDS) to be 
sent to the client unit (CU) by executing Instruc- 
tion element generating units (CO, ARG, SUB) 
of the selected instruction format node (NO). 

24. A data carrier for a server side having computer 
readable storage code embodied therein which 
comprises: 

a) a unit (CDPP) for providing one or more con- 
tent data request properties (CDPP) of the con- 
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tent data request (CDRQ) made by a client unit 
(CU); 

b) a unit (IFSET) for preparing an instruction 
data set (IDS) having the instruction format (IF) 5 
and consisting of a plurality of instruction ele- 
ment data sets (I EDS) each representing a par- 
ticular instruction element (IE) of the instruction 
format (IF) and generated by one or more in- 
struction element generating units (CO, ARG, 10 
SUB) of said unit (IFSET) for preparing an in- 
struction data set; 

c) a unit (IFCFG) containing a tree data struc- 
ture (TRE) consisting of a plurality of instruction is 
format nodes (NO; NO, N1 , N2; H1 , Ht .1 , H1 .2, 

H1 .3; INCL), each instruction format node (NO) 
indicating a particular combination of instruc- 
tion elements (IE) constituting a particular in- 
struction format (IF) and having associated with 20 
It a node selection criterion (OP, RE. VAL); 

d) a unit (IFSEL) for searching said tree data 
structure (TRE) with the determined content 
data request properties (CDPP) and for select- 2$ 
ing an instruction format node (IFNO) whose 
associated node selection condition ((OP, RE, 
VAL) matches said determined content data re- 
quest properties (CDPP); and 

30 

e) said unit (IFSET) for preparing an Instruction 
data set being adapted for preparing the in- 
struction data set (IDS) to be sent to the client 
unit (CU) executing the instruction element 
generating units (CO, ARG, SUB) of the select- 35 
ed instruction format node (NO). 

25. A data communication system (SYS) compris- 
ing one or more server units (SERV) according to 
one or more of claims 1 -1 7 and one or more client *o 
units (CU). 

26. A server unit (SERV) of a data processing sys- 
tem (DPS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS) in a particular instruction for- 
mat (IF) in response to a content data request 
(CDRQ), comprising: 

c) an instruction format configuration file so 
(IFCFG) containing a tree data structure (TRE) 
consisting of a plurality of instruction format 
nodes (NO; NO, N1, N2; H1, H1.1, H1.2, H1.3; 
INCL), each Instruction format node (NO) indi- 
cating a particular combination of instruction el- 55 
ements (IE) constituting a particular instruction 
format (IF) and having associated with It a node 
selection criterion (OP, RE, VAL); and 




d) an instruction format selection unit (IFSEL) 
for searching said tree data structure (TRE) 
with content data request properties (CDPP) 
relating to a content data request (CDRQ) sent 
by the client unit (CU) and for selecting an in- 
struction format node (IFNO) whose associated 
node selection condition ((OP, RE, VAL) match- 
es said content data request properties 
(CDPP). 

27. A method in a data processing system (DPS) 
for providing one or more client units (CU) by aserv- 
er unit (SERV) with an instruction data set (IDS) in 
a particular instruction format (IF) In response to a 
content data request (CDRQ), comprising the fol- 
lowing steps: 

c) preparing a tree data structure (TRE) con- 
sisting of a plurality of instruction format nodes 
(NO; N0.N1.N2; H1. H1.1, HI .2, H1.3; INCL), 
each instruction format node (NO) indicating a 
particular combination of instruction elements 

(IE) constituting a particular instruction format 

(IF) and having associated with it a node selec- 
tion criterion (OP, RE, VAL); and 

d) searching said tree data structure (TRE) with 
content data request properties (CDPP) relat- 
ing to a content data request (CDRQ) sent by 
the client unit (CU) and for selecting an instruc- 
tion format node (IFNO) whose associated 
node selection condition ((OP, RE, VAL) match- 
es said content data request properties 
(CDPP). 

26. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS) in a particular instruction for- 
mat (IF), wherein the server unit (SERV) is adapted 
to make the instruction format (IF) of the instruction 
data set (IDS) flexibly dependent on the capabilities 
of the client unit (CU) and/or the properties of the 
content data (CD). 

29. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data sat (IDS) in a particular instruction for- 
mat (IF), wherein the server unit (SERV) is adapted 
to make the generation and retrieval of the content 
data (CD) and Its format (IF) flexibly dependent on 
properties of the client unit (CU) and/or the proper- 
ties of resource units which provide said content da- 
ta (CD). 

30. A server unit (SERV) according to claim 29, 
wherein 
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said server unit (SERV) comprises, for the flexible 
generation and retrieval of the content data (CD), a 
selection unit (IFSEL) adapted to select from a 
number of instruction format templates (ITEMP) a 
particular instruction format template (ITEMP) de- * 
pendent on client properties and/or resource prop- 
erties, wherein said template describes at what 
places in the instruction data set (IDS) particular in- 
struction elements (IE) can be placed; and 
one or more instruction element generating units 10 
(IEGU) adapted for inserting content data (CD) in 
the places indicated in the instruction format tem- 
plate (ITEMP); 
wherein 

the selection unit (IFSEL) also selects the one or 
more Instruction element generating units (IEGU) in 
accordance with the client capabilities or resource 
capabilities, from several available instruction ele- 
ment generating units (IEGU). 

20 

31 . A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS) in a particular instruction for- 
mat (IF), wherein the server unit (SERV) comprises: & 

a selection unit (IFSEL) adapted to select from 
a number of instruction format templates 
(ITEMP) a particular instruction format tern* 
plate (ITEMP) dependent on client properties 30 
and/or resource properties, wherein said tem- 
plate describes at what places in the instruction 
data set (IDS) particular Instruction elements 
(IE) can be placed; and 

35 

one or more instruction element generating 
units (IEGU) adapted for inserting content data 
(CD) in the places indicated in the instruction 
format template (ITEMP) ; wherein 

40 

the selection unit (IFSEL) also selects the one 
or more Instruction element generating units 
(IEGU) in accordance with the client capabili- 
ties or resource capabilities, from several avail- 
able instruction element generating units 
(IEGU). 

32. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 

are provided by the server unit (SERV) with an in- so 
struction data set (IDS) in a particular instruction for- 
mat (IF), wherein the server unit (SERV) Is adapted 
to make the Instruction format (IF) of the Instruction 
data set (IDS) flexibly dependent on the properties 
of the client unit (CU) and/or the properties of the ss 
requested content data (CD) obtained by a content 
data request property provider unit (CDPM) which 
is adapted to analyse a content data request (RM) 



from the client unit (CU) to provide said one or more 
client unit related properties and content data relat- 
ed properties. 

33. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS) in a particular Instruction for- 
mat (IF), wherein the server unit (SERV) is adapted 
to make the instruction format (IF) of the instruction 
data set (IDS) flexibly dependent on client unit re- 
lated properties stored in a first property memory 
(MEM1) and/or content data related properties 
stored in a second memory (MEM2). 

34. A method in a data processing system (DPS) 
for providing one or more client units (CU) by a serv- 
er unit (SERV) with an instruction data set (IDS) in 
a particular instruction format (IF) in response to a 
content data request (CDRQ) in which client unit 
(CU) related properties and/or content data related 
properties are provided in a property provision pro- 
cedure (SS1) preceding a procedure (SS2) in which 
the instruction data set is provided to the client unit 
(CU) In an instruction data set provision procedure. 

35. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS), wherein the server unit 
(SERV) Is adapted to make the provision of the in- 
struction data set dependent on searching a tree 
structure in a configuration file (IFCFG) with some 
client unit (CU) related and/or content data related 
properties, wherein each node in the tree structure 
generates the Instruction data set (IDS) in a differ- 
ent instruction format (IF). 

36. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS), wherein the server unit 
(SERV) is adapted to make the provision of the in- 
struction data set dependent on searching a tree 
structure in an XML configuration file (IFCFG) with 
some client unit (CU) related and/or content data 
related properties, wherein each node in the tree 
structure generates the instruction data set (IDS) in 
a different instruction format (IF) wfth a screen tem- 
plate (ITEMP) generated by a template JSP (JAVA 
Server pages) or a serviet with a set of argument 
serviets and describing at what positions the argu- 
ments are to be inserted in the template (ITEMP). 

37. A server unit (SERV) according to claim 36, 
wherein said tree structure Is generated separately 
for each session between the client unit (CU) and 
the server unit (SERV). 
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38. A server unit (SERV) according to claim 36, 
wherein said tree structure is generated once and 
independently for each session between the client 
unit (CU) and the server unit (CU). 

5 

39. A server unit (SERV) according to claim 36, 
wherein said tree structure is generated dependent 
on client-related properties and/or content data 
properties. 

10 

40. A server unit (SERV) of a data processing sys- 
tem (SYS) in which one or more client units (CU) 
are provided by the server unit (SERV) with an in- 
struction data set (IDS), wherein the server unit 
(SERV) is adapted to determine client unit related » 
properties and content data related properties by 
analysing a content data request (RM) form the cli- 
ent unit (CU). 

20 
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FIG.lOb 



xml file for main nodes main 

<?xml version="1.0"encoding= "ISO-8859-1"? > 
<!- sreen definitions -> 
- <node> 

4 <!- default screen --> 

/ - <screen template="/htm|/HTMLTemplate,jsp " class=" default > 
NO <component name= Title M value="www.mYdomain.com" direct="true"/> 
- <component name= "Background" value="/html/HTMLBackground.jsp7> 

orgument name="picture" value ="$BACKGR0UND_PICTURE7> 
</component> 

<component name= "Error" value ="/htm|/HTMLError.jsp"/> 
</screen> 

<!-- execute login --> 

-<node> HtiTK 
/ -< operation type = "and" > >< 
/ < requirement tyoe = "requestParameter" name = "cmd" ' 
Nt value ="execute_login7> 

< requirement type = "executionEnvironmenf name^'loginBean" 
value="null"/> 
</operation> 

<screen template = "/portal/login" class= "login"/> 
</node> 
<!-- logout -> 
- <node> 

4 <requirement type= "requestParameter" name= n cmd" value = "logout /> 
' <screen template= "/portal/logout" class= "logout7> 
™ z </node> 

<!- include screen definition files for different devices supported 
--> 

< include file= "etc/screenregistries/porta|/ScreenRegistry_ wmUml" /> 

< include file= "etc/screenregistries/porta|/ScreenRegistry_ pqajcml" /> 
<include file = "etc/screenregistries/portal/ScreenRegistry_ xuLxml" /> 
<include file= "etc/screenregistries/porta(/ScreenRegistry_ html.xml"/> 

<7node> 

IFSEL 
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FIG.lOc 
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FIG.lOd xml file of HTML nodes HTML 

<?xml version = "1.0" encoding= n IS0-8859-1"?> 
<!~ Screen definitions for standard HTML devices ( MSIE,Netscape, ...) 
-> 
- <node> 
/- < operation type = "or" > 
/ - < operation type = n not"> 
H1 <requirement type= a ccpp" name^BrowserXCPPAccepttext/html" 

value = "null v> 
</operation> 

< requirement type ~ "requestHeaderParameter" name = "user-agent" 
vaIue^Mozilfa*7> 

</operation> 
<!~ login page -> 

H1.1 - <node>. 

- <operation type== u or* > 

- <operatiantype="and ,, > 

requirement type^'executionEnvironment" name== "loginBean" 
value ="null7> 
<operation type="not" > 
<requirement type= "requestParameter* name= "cmd" 
value » "execute Jogin"/> 
</operation> 
</operation> 

<requirementtype= a requestParameter" name="page" value — "login"/> 
</operation> 

- <screen Ip^Login.Screen' 1 template^ yhtm|/HTMLtoginTempl8tejsp* 

class — "defaulP > 

<component name="Title" value = B HTMLLogin .title" <firect= "true" 

base = "com.sun.star .portal, web jsp.html7> 
<component name="CurrentContent" value = n /htmI/HTMLiogin jsp7> 
<component name="Error* value= 1 /htm(/HTMLError.jsp7> 
</screen> 
</node> 

<!~ welcome page -> 
H1.2 - <node> 

- < operation type ="01* > 

requirement type- "executionEnvironment" 
narne^ "UniversalContentBrockerContenf value= "nuII"/> 
<requirement type="resourceProperty" name= "PresentationllRL" 
value- "staroffice.privatB^actory/deslctop7> 
</operation> 

- <screen ID= "Welcome.Screen" class== 'default" > 

<component name= Tide - value = "HTMLWelcome.titJe B direct = "true" 

base = "com.sun.star.portal.webjsp.htmr/> 
<componentname= "Shortcuts' value= B /htm|/HTMLShortcuts.isp ,l /> 

< component name= "CurrentContent* 
value ="/htmI/HTMLWelcome.jsp"/> 

</screen> 
</node> 
HI 3 - <node> 

<l~ more HTML nodes ... -> 
</node> 

- substitution name= ft $BACKGROUND PICTURF > 

- <element> 

requirement type = "userlnformation" name«"gender" value=:T/> 
<result value = 6 HTMLWomensBackground.gif /> 
file: //V:\pat\ScreenRegistry_htmLxml IFSEL 
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FIG.10e 



<element> 



HTML 



- <element> 

< <requirement type= ,, use^information ,, name = "gender" value^m"/^ 

< result value = a HTMLMensBackground.grf 7> 
<element> 

- <element> 

<result value = "HTMLdefauItBackgrounigif /> 
</element> 
^substitution > 
</node> 

< !- End standard HTML description -> 
file: //V:\pat\ScreenRegistry_htmLxml 
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WML xml FILE OF WML NODES FIG.lOg 

<?xml version-°1 .0" encoding- a ISO-8859-r?> 
<!- Screen definitions for WAP (WML) devices -> 
- <node> 

- < operation type- "or" > 

- <operation type- "not" > 

<requirement type= M ccpp a 
name= fl BrowserXCPPAccept.textAmd.wap.wml u vaIue-"nuil B > 
</operation> 

<requirement type- "requestHeaderParameter" name-*user-agent" 
value- "Wapalizer*Y> 

< requirement type = "requestHeaderParameter" name- "user-agent" 

value- u Nokia 4 "/> 
<requirement type= B rQquestHGaderParameter a name-"usef-agent" 

value=°R380"/> 
<requirement type- "requestHeaderParameter" name -"user-agent" 

value-"ERKOUP/4.0.10"/> 
<requirement type- "requestHeaderParameter" name- "user-agent" 

value-"AWVUP/4.0.10 # "/> 

< requirement type= "requestHeaderParameter" name -"user-agent" 
value- "SP01 UP/4.0.10"/> 

<requirement type- "requestHeaderParameter" name -"user-agent* 

value- T250 UP/4. 0.10 # V> 
<requirement type- "requestHeaderParameter" name -"user-agent 0 

value- "MKUP/4.0jVv> 
requirement type="requestHeaderParameter p name- "user-agent" 

valuer "MOT-CB/0.0.18 UP/4.0.10*7> 
<requirement type- "requestHeaderParameter" name= "user-agent" 

value- "SHUP/4.0.10*7> 
</operation> 

- <screen template— 7wml/WMLTemplate.isp" class="wml B > 

< component name - B Error" value - VwmVWMLError.jspV> 
</$creen> 

<!- login page ~> 

- <node> 

- <operationtype-"or"> 

- < operation type- "and" > 

<requirement type-'executionEnvironment" name-loginBean 0 
value = n nulI7> 
- < operation type = "not" > 

< requirement type -"requestParameter 4 name- "cmd* 

value- "execute Jogin"/> 
</operation> 
</operation> 

<requirement type -"requestParameter" name - "page" value- "login"/ 
</operation> 

- <screen template- Ywml/WMLLGginTemplatejsp ,, class- "login" > 

<ccmponent name- "Deck 1" value -7wmlWMLLoginjsp7> 
<component name- "Error"*' value=Vwm(/WMLError.jsp7> 
</screen> 
</node> 

<!- welcome page -> 
- <node> 

< requirement type - "executionEnvironment" 
name - °UniversalContentBrockerContent" value = "nulI7> 

- <screen class= u wmr> 

<componente name= fl Deck_1" value= °wmI/WMLWelcome.jsp7> 

file: //V^pat\ScreenRegistrY_wm!.xml IFSEL 
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FIG.lOh 



</screen > 
</node> 



WML 



<!~ module explorer -> 
- <node> 

- <operation type-°or B > 

requirement typa= B resourceProperty n name = "protocol" 

requirement type = M re$ourceProp8rty" name="protocoi B 
value =°ftp:7> 
</operation> 

- <screen class = tt wml'> 

- < component name~"DecM u value= ,, $WMLEXPLORER B > 

<argument name- u explorertype B value="explorer7> 
<argument name^'title" vaIue= B WML£xp!orer\documents7> 
</component > 
</screen> 

- <node> 

< requirement type^requestParameter* name B cmd n 
value = °vie wRage B /> 

- <screen class^Vml^ 

<component name='Action" value =7porta(/viewpage u /> 

- </screen> 
</node> 

- <node> 

<requirement type= "requestParameter" name- "cmd" 
value = n rename7> 

- <screen class = n wrnl u > 

<component name = "Deck J" value="WMLRename.jsp7> 
</screen> 
</nocfe> 

- <node> 

<requirement type- u requestParameter B name= °cmd B value = B delete7> 
♦ </screen class = l, wmr> 

<component name= u Action - value = Vportal/delete7> 

</screen> 
</node> 

- <node> 

< requirement type = "requestParameter" name= u cmd B 
value= *execute_mail rt /> 

- <screenclass="wmr> 

<component name = "Action" value='/porta|/mail"/> 
- <component name = "Deck J B value="lfWML£XPLORER a > 
orgument name = t, exploTBrtype 8 value = B explorer7> 
orgument name- W value= B WMLE^Iorer f documents7> 
</component> 
<component name= 'Error" 
va!ue= 7wml/WMLMailSendEnrorjspV> 
</screen> 
</node> 

- <node> 

<requirement type = n requestParameter B name= B cmd" 
value = D 8xecut8_ne wJolder < 7> 

- < screen class = u wml n > 

<component name= M Action M value= B /portal/newFolder a /> 
</screen> 
</node> 

- <node> 

fife: //V:\oat\ScreenRegistry wml.xml IFSEL 
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FIG.lOi 



WML 

requirement type^requestParameter" name=°submoduleV> 
vaue= ll menu7> „ 

- <screentemplate=Vwml/WMLTemplatejsp;^ "contextmenu^ 

^component name ="Deck J "value -7wml/WMLCommands.jsp7> 
</screen> 
</node> 
<node> 
<node> 

<!- more WML nodes ... --> 
</node> 

substitution name= tt $WMLEXPLORER tt > 

- < element > u . _ _ . n 

<requirement type= "requestParameter a name= tt viewTypeExplorer 

value= tt fileview ,, /> _ w . . 
<result value= 7wml/WMLRIeView.jsp7> 
</element> 

- <element> . 

<result value=7wml/WMLFolderView.jsp n /> 

</element> 
</substitution> 
</node> 

< u End WAP (WML) description ~> 
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